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 iss
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 other issue when
> >> multiple
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 difficult
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.
> >
>
> My use case is not real
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 versi
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 (ParseState->p
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
>
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 ide
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
differen
