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
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 |
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 |