On Wed, Nov 7, 2012 at 11:45 AM, Josh Berkus wrote:
>
>> You're being obtuse, Josh. These parameters can be set the same way any
>> other parameters can, including ALTER ROLE SET or ALTER DATABASE SET.
>> The "superuser only" restriction is that only a superuser can execute
>> the ALTER, not that
Josh Berkus writes:
> It still eliminates the main potential use of auto-explain on production
> sites, though, which is to turn it on only for specific operations.
> I've never been able to make use of auto-explain for any real diagnostic
> purpose on a production site, and I don't personally kno
> You're being obtuse, Josh. These parameters can be set the same way any
> other parameters can, including ALTER ROLE SET or ALTER DATABASE SET.
> The "superuser only" restriction is that only a superuser can execute
> the ALTER, not that the target role has to be superuser.
Oh? Ok, that's hel
Josh Berkus writes:
>> You can reduce the logging volume on busy servers with
>> auto_explain.log_min_duration. You can also activate it for a single
>> database user only by setting log_min_duration to -1 globally and
>> change the setting for one user with ALTER ROLE SET, right?
> Not accordin
> You can reduce the logging volume on busy servers with
> auto_explain.log_min_duration. You can also activate it for a single
> database user only by setting log_min_duration to -1 globally and
> change the setting for one user with ALTER ROLE SET, right?
Not according to the docs, you can't.
Josh Berkus wrote:
>> Huh? The typical use-case is to enable it for all sessions by
>> including it in shared_preload_libraries. That doesn't require any
>> particular session to be superuser. (If you're superuser you can then
>> turn it *off* in your session, should you wish.)
>
> It's not pra
> Huh? The typical use-case is to enable it for all sessions by
> including it in shared_preload_libraries. That doesn't require any
> particular session to be superuser. (If you're superuser you can then
> turn it *off* in your session, should you wish.)
It's not practical to have auto-explai
On Sun, Nov 4, 2012 at 1:35 AM, Pavel Stehule wrote:
> Hello
>
> 2012/11/4 Satoshi Nagayasu :
>>>
>>
>> Do we have something to add to auto_explain?
>
> Now I am working on expanding slow query record and auto_explain with
> some locking times (lock on objects, lock on enhancing pages, other
> loc
Josh Berkus writes:
>> Do we have something to add to auto_explain?
> Well, to be frank, I've never found auto-explain to be useful because of
> its restriction to superuser sessions. It's an interesting
> proof-of-concept, but completely useless at any production site.
Huh? The typical use-ca
> I think auto_explain would help you solve such rare incidents
> if it could dump several statistics into server log, including lock
> waits and block reads/writes statistic per-session, for example.
>
> Do we have something to add to auto_explain?
Well, to be frank, I've never found auto-expla
Hello
2012/11/4 Satoshi Nagayasu :
> (2012/11/03 10:44), Josh Berkus wrote:
>>
>>
>>> I don't see all that going into core without a much bigger push than I
>>> think people will buy. What people really want for all these is a
>>> proper trending system, and that means graphs and dashboards and
>
(2012/11/03 10:44), Josh Berkus wrote:
I don't see all that going into core without a much bigger push than I
think people will buy. What people really want for all these is a
proper trending system, and that means graphs and dashboards and
bling--not a history table.
Well, I'm particularly
> I don't see all that going into core without a much bigger push than I
> think people will buy. What people really want for all these is a
> proper trending system, and that means graphs and dashboards and
> bling--not a history table.
Well, I'm particularly thinking for autoconfiguration. Fo
On 11/1/12 11:54 PM, Josh Berkus wrote:
For example, it would be really useful to be able to
see, for example, pg_stat_user_tables from 2 days ago to estimate table
growth and activity, or pg_stat_replication from 10 minutes ago to
average replication lag.
I don't see all that going into core w
On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus wrote:
> Greg,
>
> First off, let me again praise the great work you and Peter are doing in
> this area.
> > Modeling this on pg_stat_statements includes the hope of packaging it as
> > an extension with minor core hooks, and the idea that there would b
Greg,
First off, let me again praise the great work you and Peter are doing in
this area.
> Modeling this on pg_stat_statements includes the hope of packaging it as
> an extension with minor core hooks, and the idea that there would be a
> fixed size list of timing events available at any time. C
Parsing log files for commonly needed performance data is no fun. As a
next step toward eliminating that, I've been working on how to approach
this similarly to how pg_stat_statements can cut down on query log
processing. I thought it would be novel to outline this for design
review before co
17 matches
Mail list logo
