RE: pg_stat_statements HLD for futur developments

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: legrand legrand <legrand_legrand(at)hotmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: pg_stat_statements HLD for futur developments
Date: 2018-03-22 12:51:51
Message-ID: alpine.DEB.2.20.1803221340180.23833@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

> My question is more as there are so many developments arround
> pg_stat_statements (see the list at the end of the initial post):
>
> What is the roadmap for its design ?

None? As for any feature, some people may have some plans, that they may
end up developing or not. If developed, it may end up committed or not.
Kind of a Darwinian process which involves a degree of randomness.

> Could a PLANID column be added to help new developments working on plans and parameters ?

Dunno. I understand that the underlying suggestion is that selected plans
may be kept as queries are kept, and that you are refering to
"https://commitfest.postgresql.org/17/1470/".

Maybe ask your question on the corresponding thread, and contribute to
reviewing the patch?

As the same plan may be used for two distinct queries and one query may
yield distinct plans, I'd guess that there is a potential n-n
relationship, but maybe it is simpler to keep a list of plans attached to
their queries somehow.

> Could all the new columns be added to the actual view, or should they be
> added to others like pg_stat_statements_plans or
> pg_stat_statements_parameters reusing pgss's pk (userid, dbid, queryid,
> planid) ?

Out of the box I'd be fine with a pg_stat_plans, and some mapping between
plans and statements.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-03-22 13:18:40 Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Previous Message Alexander Korotkov 2018-03-22 12:49:37 Re: [HACKERS] GUC for cleanup indexes threshold.