Thread

Commits

  1. pg_stat_statements: track number of rows processed by some utility commands.

  1. pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    legrand legrand <legrand_legrand@hotmail.com> — 2020-03-15T17:35:55Z

    Hello,
    it seems that column "rows" is not updated after CREATE TABLE AS SELECT
    statements.
    
    pg13devel (snapshot 2020-03-14)
    postgres=# select name,setting from pg_settings where name like 'pg_stat%';
                   name               | setting
    ----------------------------------+---------
     pg_stat_statements.max           | 5000
     pg_stat_statements.save          | on
     pg_stat_statements.track         | all
     pg_stat_statements.track_utility | on
    (4 rows)
    
    postgres=# select pg_stat_statements_reset();
     pg_stat_statements_reset
    --------------------------
    
    (1 row)
    
    
    postgres=# create table ctas as select * from pg_class;
    SELECT 386
    postgres=# select query,calls,rows from pg_stat_statements where query like
    'create table ctas%';
                        query                    | calls | rows
    ---------------------------------------------+-------+------
     create table ctas as select * from pg_class |     1 |    0
    (1 row)
    
    after modifying the following line in pg_stat_statements.c
    
    rows = (qc && qc->commandTag == CMDTAG_COPY) ? qc->nprocessed : 0;
    into
    rows = (qc && (qc->commandTag == CMDTAG_COPY 
                          || qc->commandTag == CMDTAG_SELECT)
               ) ? qc->nprocessed : 0;
    
    column rows seems properly updated.
    
    What do you think about that fix ?
    Thanks in advance
    Regards
    PAscal
    
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
    
    
    
    
  2. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    legrand legrand <legrand_legrand@hotmail.com> — 2020-03-25T22:39:03Z

    Same remark for syntax
    
    CREATE MATERIALIZED VIEW
    
    as well.
    
    Regards
    PAscal
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
    
    
    
    
  3. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-03-26T12:41:34Z

    
    On 2020/03/16 2:35, legrand legrand wrote:
    > Hello,
    > it seems that column "rows" is not updated after CREATE TABLE AS SELECT
    > statements.
    > 
    > pg13devel (snapshot 2020-03-14)
    > postgres=# select name,setting from pg_settings where name like 'pg_stat%';
    >                 name               | setting
    > ----------------------------------+---------
    >   pg_stat_statements.max           | 5000
    >   pg_stat_statements.save          | on
    >   pg_stat_statements.track         | all
    >   pg_stat_statements.track_utility | on
    > (4 rows)
    > 
    > postgres=# select pg_stat_statements_reset();
    >   pg_stat_statements_reset
    > --------------------------
    > 
    > (1 row)
    > 
    > 
    > postgres=# create table ctas as select * from pg_class;
    > SELECT 386
    > postgres=# select query,calls,rows from pg_stat_statements where query like
    > 'create table ctas%';
    >                      query                    | calls | rows
    > ---------------------------------------------+-------+------
    >   create table ctas as select * from pg_class |     1 |    0
    > (1 row)
    
    Thanks for the report! Yeah, it seems worth improving this.
    
    > after modifying the following line in pg_stat_statements.c
    > 
    > rows = (qc && qc->commandTag == CMDTAG_COPY) ? qc->nprocessed : 0;
    > into
    > rows = (qc && (qc->commandTag == CMDTAG_COPY
    >                        || qc->commandTag == CMDTAG_SELECT)
    >             ) ? qc->nprocessed : 0;
    > 
    > column rows seems properly updated.
    > 
    > What do you think about that fix ?
    
    The utility commands that return CMDTAG_SELECT are
    only CREATE TABLE AS SELECT and CREATE MATERIALIZED VIEW?
    I'd just like to confirm that there is no case where "rows" must not
    be counted when CMDTAG_SELECT is returned.
    
    BTW, "rows" should be updated when FETCH or MOVE is executed
    because each command returns or affects the rows?
    
    Regards,
    
    -- 
    Fujii Masao
    NTT DATA CORPORATION
    Advanced Platform Technology Group
    Research and Development Headquarters
    
    
    
    
  4. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    legrand legrand <legrand_legrand@hotmail.com> — 2020-03-27T17:43:15Z

    Thank you for those answers !
    
    > The utility commands that return CMDTAG_SELECT are
    > only CREATE TABLE AS SELECT and CREATE MATERIALIZED VIEW?
    > I'd just like to confirm that there is no case where "rows" must not
    > be counted when CMDTAG_SELECT is returned.
    
    I don't have any in mind ...
    
    > BTW, "rows" should be updated when FETCH or MOVE is executed
    > because each command returns or affects the rows?
    
    Yes they should, but they aren't yet (event with CMDTAG_SELECT added)
    
    Note that implicit cursors behave the same way ;o(
    
    postgres=# do $$ declare i integer; begin for i in (select 1 ) loop null;
    end loop;end; $$;
    DO
    postgres=# select calls,query,rows from pg_stat_statements;
     calls |                                      query                                     
    | rows
    -------+---------------------------------------------------------------------------------+------
         1 | select pg_stat_statements_reset()                                              
    |    1
         1 | (select $1 )                                                                   
    |    0
         1 | do $$ declare i integer; begin for i in (select 1 ) loop null; end
    loop;end; $$ |    0
    (3 rows)
    
    Regards
    PAscal
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
    
    
    
    
  5. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-04-20T15:42:48Z

    
    On 2020/03/28 2:43, legrand legrand wrote:
    > Thank you for those answers !
    > 
    >> The utility commands that return CMDTAG_SELECT are
    >> only CREATE TABLE AS SELECT and CREATE MATERIALIZED VIEW?
    >> I'd just like to confirm that there is no case where "rows" must not
    >> be counted when CMDTAG_SELECT is returned.
    > 
    > I don't have any in mind ...
    
    I found that SELECT INTO also returns CMDTAG_SELECT.
    
    > 
    >> BTW, "rows" should be updated when FETCH or MOVE is executed
    >> because each command returns or affects the rows?
    > 
    > Yes they should, but they aren't yet (event with CMDTAG_SELECT added)
    > 
    > Note that implicit cursors behave the same way ;o(
    
    Thanks for confirming this!
    
    Attached is the patch that makes pgss track the total number of rows
    retrieved or affected by CREATE TABLE AS, SELECT INTO,
    CREATE MATERIALIZED VIEW and FETCH. I think this is new feature
    rather than bug fix, so am planning to add this patch into next CommitFest
    for v14. Thought?
    
    Regards,
    
    -- 
    Fujii Masao
    Advanced Computing Technology Center
    Research and Development Headquarters
    NTT DATA CORPORATION
    
  6. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    legrand legrand <legrand_legrand@hotmail.com> — 2020-04-21T11:37:12Z

    Fujii Masao-4 wrote
    > Attached is the patch that makes pgss track the total number of rows
    > retrieved or affected by CREATE TABLE AS, SELECT INTO,
    > CREATE MATERIALIZED VIEW and FETCH. I think this is new feature
    > rather than bug fix, so am planning to add this patch into next CommitFest
    > for v14. Thought?
    
    Thanks !
    maybe v13, if this was considered as a bug that don't need backport ?
    
    Regards
    PAscal
    
    
    
    --
    Sent from: https://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
    
    
    
    
  7. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-04-22T03:17:11Z

    
    On 2020/04/21 20:37, legrand legrand wrote:
    > Fujii Masao-4 wrote
    >> Attached is the patch that makes pgss track the total number of rows
    >> retrieved or affected by CREATE TABLE AS, SELECT INTO,
    >> CREATE MATERIALIZED VIEW and FETCH. I think this is new feature
    >> rather than bug fix, so am planning to add this patch into next CommitFest
    >> for v14. Thought?
    > 
    > Thanks !
    > maybe v13, if this was considered as a bug that don't need backport ?
    
    Yeah, if many people think this is a bug, we can get it into v13.
    But at least for me it looks like an improvement of the capability
    of pgss rather than a bug fix. If the document of pgss clearly
    explained "pgss tracks the total number of rows affect by even
    utility command ...", I think that we can treat this as a bug. But...
    
    Regards,
    
    -- 
    Fujii Masao
    Advanced Computing Technology Center
    Research and Development Headquarters
    NTT DATA CORPORATION
    
    
    
    
  8. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    Asif Rehman <asifr.rehman@gmail.com> — 2020-05-06T13:49:23Z

    The following review has been posted through the commitfest application:
    make installcheck-world:  tested, passed
    Implements feature:       tested, passed
    Spec compliant:           not tested
    Documentation:            not tested
    
    The patch applies cleanly and works as expected.
  9. Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-07-29T14:24:33Z

    
    On 2020/05/06 22:49, Asif Rehman wrote:
    > The following review has been posted through the commitfest application:
    > make installcheck-world:  tested, passed
    > Implements feature:       tested, passed
    > Spec compliant:           not tested
    > Documentation:            not tested
    > 
    > The patch applies cleanly and works as expected.
    
    Thanks for the review and test!
    Since this patch was marked as Ready for Committer, I pushed it.
    
    Regards,
    
    
    -- 
    Fujii Masao
    Advanced Computing Technology Center
    Research and Development Headquarters
    NTT DATA CORPORATION