On Thu, Oct 9, 2014 at 2:41 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > I think the theory for track_io_timing being PGC_SUSET is that if the > superuser turned it on, no one should be able to turn it off. > > But I don't see an argument for the other way around, that no one should be > able to turn it on locally of the superuser left it at the default of off. > > So I think the real behavior we would want is that anyone can turn it on in > their session, and can also turn it off provided it was turned on by them in > the first place. But there is no machinery in the GUC code to do that, > which is probably why it wasn't done. I meant to work on that for this dev > cycle, but I never dug into how to implement the "provided it was turned on > by them in the first place" part of the requirement. And how would this be > expressed generically? Some notion that the default value can be a floor or > ceiling which the user can alter in one direction, and reverse that > alteration. PGC_SUSET_FLOOR and PGC_SUSET_CEILING?
Hmm. IIRC, there are only two use cases for I/O timing at present: pg_stat_statements (which really only makes sense if it's turned on or off system-wide) and EXPLAIN. Rather than inventing more GUC machinery, I think we could just add an explain flag called "IO". So you could do: EXPLAIN (ANALYZE, IO) SELECT .... And that would gather I/O stats even if it's turned off system-wide. Or you could do: EXPLAIN (ANALYZE, IO false) SELECT .... That can't really be allowed to suppress gathering the I/O stats for this query if the sysadmin wants those stats for all queries. But it could suppress the print-out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers