On Thu, May 21, 2020 at 3:17 PM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: > On Tue, May 19, 2020 at 4:29 AM Andy Fan <zhihui.fan1213@gmail.com> wrote: >> Thanks for the excellent extension. I want to add 5 more fields to satisfy the >> following requirements. >> >> int subplan; /* No. of subplan in this query */ >> int subquery; /* No. of subquery */ >> int joincnt; /* How many relations are joined */ >> bool hasagg; /* if we have agg function in this query */ >> bool hasgroup; /* has group clause */ > > Most of those fields can be computed using the raw sql satements. Why > not adding functions like query_has_agg(querytext) to get the > information from pgss stored query text instead?
Yeah I personally find concepts related only to the query string itself not something that needs to be tied to pg_stat_statements. While reading about those five new fields, I am also wondering how this stuff would work with CTEs. Particularly, should the hasagg or hasgroup flags be set only if the most outer query satisfies a condition? What if an inner query satisfies a condition but not an
outer query? Should joincnt just be the sum of all the joins done in all queries, including subqueries?
The semantics is for overall query not for most outer query. see codes
> Most of those fields can be computed using the raw sql satements. Why > not adding functions like query_has_agg(querytext) to get the > information from pgss stored query text instead?
That mainly because I don't want to reparse the query again.
