Re: pg_stat_statements and "IN" conditions - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id dnw6k65xxyxuo3verjazc7cwbszsvzjju7clotrtatchyscwrd@az4krz5emji4
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
> On Tue, Mar 18, 2025 at 07:33:25PM GMT, Álvaro Herrera wrote:
>
> By the way, I'm still open to adding the 'powers' mechanism that was
> discussed earlier and other simple additions on top of what's there now,
> if you have some spare energy to spend on this.  (For full disclosure:
> the "powers" thing was discussed in a developer's meeting last year, and
> several people said they'd prefer to stick with 0001 and forget about
> powers, on the grounds that it produced query texts that were weird and
> invalid SQL.  But now that we have the commented-out syntax, it's no
> longer invalid SQL, and maybe it's not so weird either.)
>
> But there are other proposals such as handling Params and whatnot.  At
> this point, what we'd need for that is a more extensive test suite to
> show that we're not breaking other things ...

Yes, I'm planning to continue working on this topic, there are still
plenty of things that could be improved.

> One thing I noticed while going over the code, is that we say in some
> code comments that the list of elements only contributes the first and
> last elements to the jumble.  But this is not true -- the list actually
> contributes _nothing at all_ to the jumble.  I don't think this causes
> any terrible problems, but maybe somebody will discover that I'm wrong
> on that.  This isn't trivial to solve, because if you try to add
> anything to the jumble from there, you'd break the first/last location
> pair matching.  We could maybe fix this by returning the actual
> bottommost Const node from IsSquashableConstList() instead of whatever
> is wrapping it, and then arrange for _jumbleConst() to receive a boolean
> that turns off jumbling of the location.
>
> However, contributing nothing already makes such a query different from
> another query that has exactly one element, because that one jumbles
> that element.  It could only be confused (in the sense of identical
> query_ids) with another list that has zero elements.
>
> Anyway, something to play with.

Yep, I don't see this as an immediate problem as well, but will do some
experiments with that.



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Snapshot related assert failure on skink
Next
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions