On Mon, Mar 24, 2025 at 10:30:59PM -0500, Sami Imseih wrote:
>> Sami Imseih <samimseih(at)gmail(dot)com> writes:
>>> I agree that some may want stats to merge for the same tables,
>>> and others may not. I will suggest this with some hesitation, but why not
>>> make this behavior configurable via a GUC?
>>> We recently introduced query_id_squash_values for controlling
>>> the merge of an IN list, maybe this is another queryId behavior we should
>>> provide a configuration for?
>>
>> I don't like that GUC and I would not like this one either. We
>> learned years ago that GUCs that change query semantics are a bad
>> idea, but apparently now we have hackers who need to relearn that
>> lesson the hard way. (Admittedly, this isn't quite *query* semantics,
>> which perhaps lessens the blast radius. But I think we're still going
>> to regret query_id_squash_values.)
>
> query_id_squash_values has a much weaker argument to exist than a
> guc to control the use of alias vs OID. Why would anyone not want
> to squash the IN list? maybe we should revisit this decision in that thread.
This part of the thread is digressing, but I'd on the side of removing
entirely the GUC and make the grouping of IN values the default. We
still have time to discuss that during the beta cycle, so let's do so
on its related thread.
--
Michael