Re: Expose options to explain? (track_io_timing)

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expose options to explain? (track_io_timing)
Date: 2014-10-09 18:41:36
Message-ID: CAMkU=1yF2ZSr3=gfKeKdVmVb+7YNqDFqNNTOKn8sXk=4Nt36fA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 9, 2014 at 10:17 AM, Joshua D. Drake <jd(at)commandprompt(dot)com>
wrote:

>
> Salut!
>
> Fellow volunteers, I request assistance in understanding the following:
>
> When I explain a query I can get the following information:
>
>
> | "I/O Read Time": 0.000,
> | "I/O Write Time": 0.000
>
> I know why it is 0. My question is this, can we expose it to explain only?
> Specifically "explain (analyze,buffers)". Is there a technical reason we
> must turn on track_io_timing for the whole system? If there isn't, is this
> something the community would want?
>

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?

Anyway, if we are going to solve this for track_io_timing, I think it would
be better so solve it in a way that it can also be used by
pg_stat_statements, as well as EXPLAIN. But maybe that doesn't make sense,
as you need to be a superuser to call pg_stat_statements_reset() anyway.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-10-09 18:50:36 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Alvaro Herrera 2014-10-09 18:29:11 Re: replicating DROP commands across servers