Re: pg_stat_statements fingerprinting logic and ArrayExpr - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pg_stat_statements fingerprinting logic and ArrayExpr
Date
Msg-id CAM3SWZTAVaLfu8q=zTErsw_AbyWTSsXWSZ2XOj3KcGZc3tX3mw@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements fingerprinting logic and ArrayExpr  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_stat_statements fingerprinting logic and ArrayExpr
List pgsql-hackers
On Tue, Dec 10, 2013 at 2:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Right, but the flip side is that you could collapse things that people
> don't want collapsed.  If you've got lots of query that differ only in
> that some of them say user_id IN (const1, const2) and others say
> user_id IN (const1, const2, const3) and the constants vary a lot, then
> of course this seems attractive.  On the other hand if you have two
> queries and one of them looks like this:
>
> WHERE status IN ('active') AND user_id = ?
>
> and the other looks like this:
>
> WHERE status IN ('inactive', 'deleted') AND user_id = ?
>
> ...it might actually annoy you to have those two things conflated;
> it's easy to imagine one having much different performance
> characteristics than the other.

That is true, but you're probably not going to be able to make any use
of the distinction in the first place, because it's just going to be a
bunch of ? ? characters as constants. You'd have to plan ahead most
likely. You might get lucky and have this exact case, and be able to
leverage the knowledge that the 2 constants in the ArrayExpr must be
the latter and 1 must be the former, but experience suggests very
probably not.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_stat_statements fingerprinting logic and ArrayExpr
Next
From: Andres Freund
Date:
Subject: Re: pg_stat_statements fingerprinting logic and ArrayExpr