On 11/29/2018 12:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
Color me skeptical --- ruleutils has never especially been designed
to be fast, and I can't see that the overhead of this is going to be
acceptable to anybody who needs pg_stat_statements in producti
On 11/29/2018 10:59 AM, Stephen Frost wrote:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them
Alvaro Herrera writes:
> On 2018-Nov-28, Tom Lane wrote:
>> Color me skeptical --- ruleutils has never especially been designed
>> to be fast, and I can't see that the overhead of this is going to be
>> acceptable to anybody who needs pg_stat_statements in production.
> Good point.
> Maybe we ca
On 11/29/2018 10:47 AM, Alvaro Herrera wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them into the text.
True. I was thinking that the qualified-names
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Nov-28, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2018-Nov-28, Tom Lane wrote:
> > >> This would also entail rather significant overhead to find out schema
> > >> names and interpolate them into the text.
> >
> > >
On 2018-Nov-28, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Nov-28, Tom Lane wrote:
> >> This would also entail rather significant overhead to find out schema
> >> names and interpolate them into the text.
>
> > True. I was thinking that the qualified-names version of the query
> > wou
Re: Tomas Vondra 2018-11-28
<1b4e4c5e-7007-cd61-aae5-4a1c248e3...@2ndquadrant.com>
> Wouldn't it be sufficient / better to just store the search_path used
> when executing the query? That should be enough to resolve the object
> names correctly, and the overhead would be much lower (both in terms
Alvaro Herrera-9 wrote
> On 2018-Nov-28, Tom Lane wrote:
>
>> This would also entail rather significant overhead to find out schema
>> names and interpolate them into the text.
>
> True. I was thinking that the qualified-names version of the query
> would be obtained via ruleutils or some simila
It's a real problem. I saw this pattern more than once already.
The people have several schemas with identical data structures as a
preparation to eventual migration of the schema to its own server in the
cloud.
So you have ten schemas, one generic user from connection pool and
pg_stat_statemen
Alvaro Herrera writes:
> On 2018-Nov-28, Tom Lane wrote:
>> This would also entail rather significant overhead to find out schema
>> names and interpolate them into the text.
> True. I was thinking that the qualified-names version of the query
> would be obtained via ruleutils or some similar me
On 11/28/18 10:46 PM, Alvaro Herrera wrote:
> On 2018-Nov-28, Tom Lane wrote:
>
>> Sergei Agalakov writes:
>>> It would help to analyze performance issues if pg_stat_statements would
>>> extend the object names to the qualified names.
>>
>> What pg_stat_statements puts out is the original que
On 2018-Nov-28, Tom Lane wrote:
> Sergei Agalakov writes:
> > It would help to analyze performance issues if pg_stat_statements would
> > extend the object names to the qualified names.
>
> What pg_stat_statements puts out is the original query text. As was
> already pointed out to you, changi
Sergei Agalakov writes:
> It would help to analyze performance issues if pg_stat_statements would
> extend the object names to the qualified names.
What pg_stat_statements puts out is the original query text. As was
already pointed out to you, changing that text is likely to break
use-cases in
13 matches
Mail list logo
