From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: auto_explain sample rate |
Date: | 2015-06-03 07:22:07 |
Message-ID: | CAFj8pRABvcJ3K2tEav017=uqS=QfhpRsE6PqnWcUgX-hv42ShQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2015-06-03 9:17 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
>
>
> On 2 June 2015 at 15:11, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>>
>>
>> 2015-06-02 9:07 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
>>
>>>
>>> For the majority of users I'm sure it's sufficient to just have a sample
>>> rate.
>>>
>>> Anything that's trying to match individual queries could be interested
>>> in all sorts of different things. Queries that touch a particular table
>>> being one of the more obvious things, or queries that mention a particular
>>> literal. Rather than try to design something complicated in advance that
>>> anticipates all needs, I'm thinking it makes sense to just throw a hook in
>>> there. If some patterns start to emerge in terms of useful real world
>>> filtering criteria then that'd better inform any more user accessible
>>> design down the track.
>>>
>>
>> same method can be interesting for interactive EXPLAIN ANALYZE too.
>> TIMING has about 20%-30% overhead and usually we don't need a perfectly
>> exact numbers
>>
>
> I don't understand what you are suggesting here.
>
using some sampling for EXPLAIN ANALYZE statement
Pavel
>
>
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2015-06-03 07:46:37 | Re: auto_explain sample rate |
Previous Message | Craig Ringer | 2015-06-03 07:17:10 | Re: auto_explain sample rate |