Hi, On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote: > > I'm not opining one way or the other on whether squashing an IN list > is desirable. My point is that a GUC is a poor way to make --- or > really, avoid making --- such decisions. The reasons we took away > from previous experiments with semantics-determing GUCs were: > > 1. The scope of effect of a GUC is seldom what you want for such > things. There are going to be some queries in which you want behavior > A, and some in which you want behavior B, and in the worst case you > want different behaviors in different parts of the same query. It's > really painful to make that happen. > > 2. Tools that are not entitled to set the value of the GUC are forced > to be prepared to cope with any setting. That can be anywhere from > painful to impossible.
Didn't that ship already sailed in pg14 when we allowed generating custom query_id? Now: > For the specific context of controlling how query jumbling happens, > there's still another problem: the actual statement-merging behavior of > pg_stat_statements will depend on the totality of settings of the GUC > across the entire system. It's not very clear to me what will happen > if different sessions use different settings, much less if people > change the setting intra-session; but I bet a lot of people will find > it surprising. 62d712ecf did no one any favors by marking that GUC > USERSET rather than something that would prevail system-wide. One of the requirement for the custom query_id was that you shouldn't be allowed to change the algorithm dynamically, at least not unless a superuser agrees to maybe break everything, which is why compute_query_id is marked as PGC_SUSET. I think that the same reasoning should apply here and if the GUC is kept it should be at least at that level.
