On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud <rjuju...@gmail.com> wrote:
> Le jeu. 21 mai 2020 à 09:17, Michael Paquier <mich...@paquier.xyz> a > écrit : > >> 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. >> ... >> > > Indeed cte will bring additional concerns about the fields semantics. > That's another good reason to go with external functions so you can add > extra parameters for that if needed. > >> There are something more we can't get from query string easily. like: 1. view involved. 2. subquery are pulled up so there is not subquery indeed. 3. sublink are pull-up or become as an InitPlan rather than subPlan. 4. joins are removed by remove_useless_joins. -- Best Regards Andy Fan
