Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements

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