On Tue, Oct 14, 2014 at 1:04 PM, Joshua D. Drake wrote:
> On 10/14/2014 10:01 AM, Robert Haas wrote:
>> 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 invent
On 10/14/2014 10:01 AM, Robert Haas wrote:
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 fla
On Thu, Oct 9, 2014 at 2:41 PM, Jeff Janes 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
On Thu, Oct 9, 2014 at 10:17 AM, Joshua D. Drake
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.
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 explai
