On Wed, Dec 30, 2015 at 05:21:05PM -0800, Peter Geoghegan wrote:
> On Wed, Dec 30, 2015 at 5:20 PM, Bruce Momjian wrote:
> > Is this a TODO?
>
> It's on my (very long) personal TODO list. It would be great if
> someone else took it, though. So, yes.
TODO added.
--
Bruce Momjian http
On Wed, Dec 30, 2015 at 5:20 PM, Bruce Momjian wrote:
> Is this a TODO?
It's on my (very long) personal TODO list. It would be great if
someone else took it, though. So, yes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Mon, Nov 30, 2015 at 02:41:02PM +0100, Shulgin, Oleksandr wrote:
> On Wed, Nov 25, 2015 at 9:13 AM, Lukas Fittl wrote:
>
> On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote:
>
> One specific justification he gave for not using pg_stat_statements
> was:
>
>
On Wed, Nov 25, 2015 at 9:13 AM, Lukas Fittl wrote:
> On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote:
>
>> One specific justification he gave for not using pg_stat_statements was:
>>
>> "Doesn’t merge bind vars in IN()" (See slide #11)
>>
>> I wonder:
>>
>> * How do other people feel ab
On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote:
> One specific justification he gave for not using pg_stat_statements was:
>
> "Doesn’t merge bind vars in IN()" (See slide #11)
>
> I wonder:
>
> * How do other people feel about this? Personally, I've seen enough
> problems of this kind i
On Tue, Nov 24, 2015 at 10:55 PM, Jim Nasby wrote:
> I'm not following your point. Obviously you can't compare int to text that
> doesn't convert back to an int, but that's not what I was talking about.
I didn't see what else you could have meant. In any case, the type
text has no involvement in
On 11/24/15 7:46 PM, Peter Geoghegan wrote:
On Tue, Nov 24, 2015 at 5:39 PM, Jim Nasby wrote:
Another not-uncommon case is IN ( '1', '2', ... , '2342' ); in other words,
treating an integer as text. A lot of frameworks like to do that and just
push the problem onto the database. I'm not sure wh
I wrote:
> Peter Geoghegan writes:
>> This is because the ArrayExpr jumble case jumbles any ArrayExpr's list
>> of elements recursively. In this case it's a list of Const nodes, and
>> the fingerprinting logic jumbles those nodes indifferently.
> I think this is a vastly oversimplified explanatio
On Tue, Nov 24, 2015 at 5:39 PM, Jim Nasby wrote:
> Another not-uncommon case is IN ( '1', '2', ... , '2342' ); in other words,
> treating an integer as text. A lot of frameworks like to do that and just
> push the problem onto the database. I'm not sure what pg_stat_statements
> would ultimately
On 11/24/15 1:29 PM, Tom Lane wrote:
So I suspect the real problem here is that we might want all of these
things to look identical to pg_stat_statements:
ARRAY[$1, $2, 42]
ARRAY[$1, $2, $3, 47]
'{1,2,3,47}'::int[]
Don't see a very clean way to do that ...
Another not-
Peter Geoghegan writes:
> On Tue, Dec 10, 2013 at 1:30 AM, Peter Geoghegan 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);
>>
>> This is because the ArrayExpr jumble case jumbles
On Tue, Dec 10, 2013 at 1:30 AM, Peter Geoghegan 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);
>
> This is because the ArrayExpr jumble case jumbles any ArrayExpr's list
> of elements r
12 matches
Mail list logo