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

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: legrand legrand <legrand_legrand(at)hotmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements
Date: 2020-04-20 15:42:48
Message-ID: 54fa2fec-b133-0fc0-4227-3e308ba68812@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

Attachment Content-Type Size
pgss_track_rows_of_utility_v1.patch text/plain 5.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message John Muehlhausen 2020-04-20 17:13:12 NOTIFY in multi-statement PQexec() not sent outside of transaction
Previous Message Bert Brezel 2020-04-20 13:20:44 Re: BUG #16341: Installation with EnterpriseDB Community installer in NT AUTHORITY\SYSTEM context not possible

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2020-04-20 15:45:39 Re: More efficient RI checks - take 2
Previous Message Antonin Houska 2020-04-20 14:31:13 Re: More efficient RI checks - take 2