Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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:

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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 >

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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

[HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

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