From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements fingerprinting logic and ArrayExpr |
Date: | 2013-12-10 22:16:23 |
Message-ID: | 10965.1386713783@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Dec 10, 2013 at 4:30 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> pg_stat_statements' fingerprinting logic considers the following two
>> statements as distinct:
>>
>> select 1 in (1, 2, 3);
>> select 1 in (1, 2, 3, 4);
>>
>> [ and some people think it shouldn't ]
> I am very wary of implementing special-case logic here even though I
> know it could be useful to some people, simply because I fear that
> there could be a near-infinite variety of situations where, in a
> particular environment, a particular distinction isn't important.
FWIW, I didn't much care for this idea either, though Robert's expressed
it better than what was rattling around in my brain this morning. There's
a very slippery slope from here to inserting all sorts of random hacks
into the query fingerprinter, and that's not someplace I want to go.
There are alternatives that the requestor could consider for making these
cases more alike, such as supplying the set of IDs as an array constant
(or parameter) to begin with.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2013-12-10 22:30:36 | Re: pg_stat_statements fingerprinting logic and ArrayExpr |
Previous Message | Tom Lane | 2013-12-10 22:08:47 | Re: stats for network traffic WIP |