On Fri, May 22, 2020 at 3:51 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote:
>
> On 2020/05/22 15:10, Andy Fan wrote:
> >
> >
> > On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud <rjuju...@gmail.com 
> > <mailto:rjuju...@gmail.com>> wrote:
> >
> >     Le jeu. 21 mai 2020 à 09:17, Michael Paquier <mich...@paquier.xyz 
> > <mailto: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 <mailto: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.
>
> If we can store the plan for each statement, e.g., like pg_store_plans
> extension [1] does, rather than such partial information, which would
> be enough for your cases?

That'd definitely address way more use cases.  Do you know if some
benchmark were done to see how much overhead such an extension adds?


Reply via email to