On Thu, May 21, 2020 at 3:17 PM Michael Paquier <mich...@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.fan1...@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 like this for example: query_characters.hasagg |= parse->hasAggs; query_characters.hasgroup |= parse->groupClause != NIL; > 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. -- Best Regards Andy Fan
