Date: Mon, 2 Mar 2020 05:01:16 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Message-ID: <1583150476569-0.post@n3.nabble.com>
In-Reply-To: 
 <CAOBaU_Y-y+VOhTZgDOuDk6-9V72-ZXdWccXo_kx0P4DDBEEh9A@mail.gmail.com>
References: 
 <OSBPR01MB46160EE594D4C0261C0A4B7694490@OSBPR01MB4616.jpnprd01.prod.outlook.com>
 <CAOBaU_bKDoMxEWLqJue8ZS-kamcwKS2zUROONjEtp_sHmbBegg@mail.gmail.com>
 <1578237055901-0.post@n3.nabble.com>
 <CAOBaU_Z9AyNbsgXmdeQeRAknjqeRfeBEDT8F8Q35DFLQU37g3A@mail.gmail.com>
 <1578247319224-0.post@n3.nabble.com>
 <CAOBaU_YwuN2k9Ays8mKq0pS8ZjLsf7zMWRFk8yb-MF0O5to_cA@mail.gmail.com>
 <1582902395847-0.post@n3.nabble.com>
 <CAOBaU_Zgrni7VjR6RDO+p11KGdURmDmEL5Jg+t8QxRqxKwsAuA@mail.gmail.com>
 <1583074536018-0.post@n3.nabble.com>
 <CAOBaU_Y-y+VOhTZgDOuDk6-9V72-ZXdWccXo_kx0P4DDBEEh9A@mail.gmail.com>
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Julien Rouhaud wrote
> On Sun, Mar 1, 2020 at 3:55 PM legrand legrand
> &lt;

> legrand_legrand@

> &gt; wrote:
>>
>> >> I like the idea of adding a check for a non-zero queryId in the new
>> >> pgss_planner_hook() (zero queryid shouldn't be reserved for
>> >> utility_statements ?).
>>
>> > Some assert hit later, I can say that it's not always true.  For
>> > instance a CREATE TABLE AS won't run parse analysis for the underlying
>> > query, as this has already been done for the original statement, but
>> > will still call the planner.  I'll change pgss_planner_hook to ignore
>> > such cases, as pgss_store would otherwise think that it's a utility
>> > statement.  That'll probably incidentally fix the IVM incompatibility.
>>
>> Today with or without test on parse->queryId != UINT64CONST(0),
>> CTAS is collected as a utility_statement without planning counter.
>> This seems to me respectig the rule, not sure that this needs any
>> new (risky) change to the actual (quite stable) patch.
> 
> But the queryid ends up not being computed the same way:
> 
> # select queryid, query, plans, calls from pg_stat_statements where
> query like 'create table%';
>        queryid       |             query              | plans | calls
> ---------------------+--------------------------------+-------+-------
>  8275950546884151007 | create table test as select 1; |     1 |     0
>  7546197440584636081 | create table test as select 1  |     0 |     1
> (2 rows)
> 
> That's because CreateTableAsStmt->query doesn't have a query
> location/len, as transformTopLevelStmt is only setting that for the
> top level Query.  That's probably an oversight in ab1f0c82257, but I'm
> not sure what's the best way to fix that.  Should we pass that
> information to all transformXXX function, or let transformTopLevelStmt
> handle that.


arf, this was not the case in my testing env (that is not up to date) :o(
and would not have appeared at all with the proposed test on 
parse->queryId != UINT64CONST(0) ...


--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html