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