Date: Sun, 1 Mar 2020 07:55:36 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Message-ID: <1583074536018-0.post@n3.nabble.com>
In-Reply-To: 
 <CAOBaU_Zgrni7VjR6RDO+p11KGdURmDmEL5Jg+t8QxRqxKwsAuA@mail.gmail.com>
References: 
 <OSBPR01MB461651369C5B06C4BAEDF4D3944F0@OSBPR01MB4616.jpnprd01.prod.outlook.com>
 <CAOBaU_bZwSHVNVX_v3+_vqmrvAE0gcp6YczWS1kL74LUZ=fMgQ@mail.gmail.com>
 <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>
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

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


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