Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECTstatements - Mailing list pgsql-bugs

From legrand legrand
Subject Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECTstatements
Date
Msg-id 1585330995153-0.post@n3.nabble.com
Whole thread Raw
In response to Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECTstatements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECTstatements
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: "Todd A. Cook"
Date:
Subject: Re: BUG #16324: bad cost estimates for generic query plans
Next
From: Tom Lane
Date:
Subject: Re: BUG #16320: GSSAPI Error