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

From: legrand legrand <legrand_legrand(at)hotmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements
Date: 2020-03-27 17:43:15
Message-ID: 1585330995153-0.post@n3.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hamid Akhtar 2020-03-27 18:22:18 Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan
Previous Message Todd A. Cook 2020-03-27 17:16:35 Re: BUG #16324: bad cost estimates for generic query plans

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2020-03-27 17:52:38 Re: Unix-domain socket support on Windows
Previous Message Asif Rehman 2020-03-27 17:33:28 Re: WIP/PoC for parallel backup