Message-ID: <7f75a4ed-f91b-4a9b-a496-4ea89f54e1de@gmail.com>
Date: Thu, 26 Mar 2026 11:30:40 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_plan_advice
To: Robert Haas <robertmhaas@gmail.com>, Lukas Fittl <lukas@fittl.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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>
 <1299934.1773938807@sss.pgh.pa.us>
 <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>
Content-Language: en-US
From: Matheus Alcantara <matheusssilv97@gmail.com>
In-Reply-To: 
 <CA+TgmoZ45n5jaNKKgbbj4-kYV8WsPvUn=Z8HnoZ7tUb_p9WKXg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/7f75a4ed-f91b-4a9b-a496-4ea89f54e1de%40gmail.com>
Precedence: bulk

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