Re: Review of: explain / allow collecting row counts without timing info

On Fri, Feb 3, 2012 at 8:12 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>>>
>>> Fixed. The default value of TIMING option did not work as intended, it
>>> was set to true even for plain EXPLAIN (without ANALYZE). In that case
>>> the EXPLAIN failed.
>>>
>>
>> I've applied this over the "show Heap Fetches in EXPLAIN ANALYZE
>> output for index-only scans" patch.  It applied and built and passes
>> installcheck.
>>
>> I have not done a full review of this, but I want to say that I want
>> this very much.  Not only can I get the row counts, but also the Heap
>> Fetches and the output of BUFFERS, without the overhead of timing.  I
>> haven't looked at contrib aspects of it at all.
>>
>> Thank you for making this.
>
> +1.
>
> After looking at this a bit, I think we can make the interface a bit
> more convenient.  I'd like to propose that we call the EXPLAIN option
> "ROWS" rather than "TIMING", and that we provide the row-count
> information if *either* ROWS or ANALYZE is specified.

If we are allowed to make big breaks with the past, I would get rid of
ANALYZE altogether.

"analyze" basically is a synonym of "explain", or is contained within
it. You can't explain anything until you have first analyzed it.

Without ANALYZE, you are explaining the analysis done by the planner.
With it, you are explaining an analysis done by the planner and the
executor.

So we could do away with ANALYZE and have TIMING, ROWS, and BUFFERS,
any of which causes the query to actually be executed, not just
planned.

I suspect we will be unwilling to make such a break with the past. In
that case, I think I prefer the originally proposed semantics, even
though I agree they are somewhat less natural. ANALYZE is a big flag
that means "This query will be executed, not just planned". If we are
not going to make a major break, but only nibble around the edges,
then I don't think we should remove the property that the query will
be executed if and only if ANALYZE is specified.

Cheers,

Jeff