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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_stat_statements fingerprinting logic and ArrayExpr
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_stat_statements fingerprinting logic and ArrayExpr