agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
Date: Mon, 2 Mar 2020 05:01:16 -0700 (MST)
Message-ID: <1583150476569-0.post@n3.nabble.com> (raw)
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>
Julien Rouhaud wrote
> On Sun, Mar 1, 2020 at 3:55 PM legrand legrand
> <
> legrand_legrand@
> > 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
view thread (127+ messages) latest in thread
Message-ID: <1583150476569-0.post@n3.nabble.com>
Permalink: ../1583150476569-0.post@n3.nabble.com/
Also on: postgresql.org/message-id/1583150476569-0.post@n3.nabble.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: legrand_legrand@hotmail.com
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
In-Reply-To: <1583150476569-0.post@n3.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox