Re: pg_stat_statements fingerprinting logic and ArrayExpr
От | Peter Geoghegan |
---|---|
Тема | Re: pg_stat_statements fingerprinting logic and ArrayExpr |
Дата | |
Msg-id | CAM3SWZTAVaLfu8q=zTErsw_AbyWTSsXWSZ2XOj3KcGZc3tX3mw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_statements fingerprinting logic and ArrayExpr (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_stat_statements fingerprinting logic and ArrayExpr
|
Список | 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 по дате отправления: