Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
On 16/10/2016 11:21, Craig Ringer wrote: > On 16 Oct. 2016 14:31, Julien Rouhaud wrote: >> >> On 16/10/2016 02:38, Jim Nasby wrote: >> > On 10/10/16 12:58 AM, Julien Rouhaud wrote: >> >> Unless you mean deparsing the Query instead of using raw source > text? I >> >> think that would solve this

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Craig Ringer
On 16 Oct. 2016 14:31, "Julien Rouhaud" wrote: > > On 16/10/2016 02:38, Jim Nasby wrote: > > On 10/10/16 12:58 AM, Julien Rouhaud wrote: > >> Unless you mean deparsing the Query instead of using raw source text? I > >> think that would solve this issue (and also the

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
On 16/10/2016 10:47, Lukas Fittl wrote: > Can somebody chime in if it would be feasible to store this in the > out-of-band query text file, and whether a patch for this would be > considered acceptable? FWIW I already have a quick and dirty patch for this, I don't think there's any major

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Lukas Fittl
On Sat, Oct 15, 2016 at 11:29 PM, Julien Rouhaud wrote: > > > BTW, after thinking about it some more, I don't see how storing the > > search_path would help at all... it's not like you can do anything with > > it unless you have a huge chunk of the parser available. > >

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
On 16/10/2016 02:38, Jim Nasby wrote: > On 10/10/16 12:58 AM, Julien Rouhaud wrote: >> Unless you mean deparsing the Query instead of using raw source text? I >> think that would solve this issue (and also the other issue when >> multiple queries are submitted at once, you get the normalized

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-15 Thread Jim Nasby
On 10/10/16 12:58 AM, Julien Rouhaud wrote: > Would another option be to temporarily set search_path to '' when > getting the query text? ISTM that would be the best option. I don't think that possible. The query text used is raw query text provided by the post_parse_analyse hook

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-09 Thread Julien Rouhaud
On 10/10/2016 05:00, Jim Nasby wrote: > On 10/7/16 4:39 AM, Julien Rouhaud wrote: >> I see two ways of fixing this. First one would be to store normalized >> queries while fully qualifiying the relation's names. After a quick look >> this can't be done without storing at least a token location in

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-09 Thread Jim Nasby
On 10/7/16 4:39 AM, Julien Rouhaud wrote: I see two ways of fixing this. First one would be to store normalized queries while fully qualifiying the relation's names. After a quick look this can't be done without storing at least a token location in RangeTblEntry nodes, which sounds like a bad

[HACKERS] pg_stat_statements and non default search_path

2016-10-07 Thread Julien Rouhaud
Hello, I've faced multiple times a painful limitation with pg_stat_statements. Queries are normalized based on the textual SQL statements, and the queryid is computed using objects' oids. So for instance with different search_path settings, we can end up with the same normalized query but