On 26/03/26 10:55, Robert Haas wrote:
I realize not having query texts reduces its effectiveness (since you
don't see which parameters produced which plan advice), but it still
helps surface which different advice strings where seen for which
query IDs, letting you identify if you're getting a mix of bad and
good plans. And I'm just really worried people will enable this on
production in shared collection mode and take down their system.
I fully admit that pg_collect_advice is crude, but I don't think
ripping out some portion of the limited functionality that it has is
going to get us where we want to be. If it hadn't collected the query
strings, it would have been useless for the purpose for which I
originally wrote it. We could add a GUC for a length limit, perhaps,
but I think the real feature that this needs to be used in the way
that you seem to want to use it is deduplication, and as I said
earlier, I think we should consider adding the advice collection logic
to pg_stat_statements rather than building an alternative version of
that module with overlapping functionality.
I also think that we should consider adding the advice string on
pg_stat_statements. It seems to make more sense to me IMHO.
Adding support for auto_explain to explain(plan_advice, ...) (or any
other custom explain option from loadable modules) would help or make
sense here? I have been thinking about this for a while.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
