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 helpful.
Josh Berkus j...@agliodbs.com 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
On Wed, Nov 7, 2012 at 11:45 AM, Josh Berkus j...@agliodbs.com 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,
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 practical to
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 j...@agliodbs.com 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
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-explain
Josh Berkus j...@agliodbs.com 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
On Sun, Nov 4, 2012 at 1:35 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
2012/11/4 Satoshi Nagayasu sn...@uptime.jp:
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
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-explain
(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
Hello
2012/11/4 Satoshi Nagayasu sn...@uptime.jp:
(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
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. For
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
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.
On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus j...@agliodbs.com 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
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
17 matches
Mail list logo
