public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matheus Alcantara <[email protected]>
To: Robert Haas <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pg_plan_advice
Date: Thu, 26 Mar 2026 11:30:40 -0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoZ45n5jaNKKgbbj4-kYV8WsPvUn=Z8HnoZ7tUb_p9WKXg@mail.gmail.com>
References: <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
<CA+TgmoaCdsuvNn6T6SfQ_0YD2Hh2+hgTXh9fTGHQhPg1zvy2rQ@mail.gmail.com>
<CA+Tgmob7ozJAs5SU6bD2RfAt4w_AmsMGz-aaVA6WeLXHkBypOg@mail.gmail.com>
<CAK98qZ1J42RoAsHnYWGPPmHziZmzmqE=Lp_O6WJ-9aKK2qjikA@mail.gmail.com>
<CA+TgmoYjcBA6dw3nwiyfDzPXTCrxTZPXDMrc2TrDJcL1cPK6iA@mail.gmail.com>
<CA+TgmoYru-vxoTKfwjQby30r2OkTXfb18Km_=VLs6qk8Akr0-g@mail.gmail.com>
<CA+Tgmoau7yJtvbeH-0kPt1Q=Gt_ezRdgM35Q1=LT665U_86Etg@mail.gmail.com>
<[email protected]>
<CA+TgmobOLrMn5jEinWNPL5SrDH1DPpo3a4j+S6-4yhsZwWgzLg@mail.gmail.com>
<CA+TgmoZUN8FT1Ah=m6Uis5bHa4FUa+_hMDWtcABG17toEfpiUg@mail.gmail.com>
<CA+TgmoYh2-kM+tscOz=jVYq9Tf4SRPVqzPojs3KLZcW6E9m1BQ@mail.gmail.com>
<CA+TgmoaK=4w7-qknUo3QhUJ53pXZq=c=KgZmRyD+k7ytqfmgSg@mail.gmail.com>
<CAP53Pkz3DSFaaowYvbO5LULf3NhydD_UhHkighfWf6_pwxiqUw@mail.gmail.com>
<CA+TgmoZ45n5jaNKKgbbj4-kYV8WsPvUn=Z8HnoZ7tUb_p9WKXg@mail.gmail.com>
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
view thread (184+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_plan_advice
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox