On 3.2.2012 18:28, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra <tv@fuzzy.cz> wrote:
>> I don't think changing the EXPLAIN syntax this way is a good idea. I think
>> that one option should not silently enable/disable others, so ROWS should
>> not enable ANALYZE automatically.
>
> I didn't propose that. The point is that the desired behavior
> (however we name it) is a SUBSET of what ANALYZE does.
>
> So we can either:
>
> 1. Have ANALYZE enable all the behavior, and have another option
> (TIMING) that can be used to turn some of it back on again.
>
> 2. Have ANALYZE enable all the behavior, and have another option
> (ROWS) that enables just the subset of it that we want.
>
> I prefer #2 to #1, because I think it's a bit confusing to have an
> option whose effect is to partially disable another option. YMMV, of
> course.
OK, thanks for the explanation. I don't like the idea of subsets as it
IMHO makes it less obvious what options are enabled. For example this
EXPLAIN (ROWS) query...
does not immediately show it's actually going to do ANALYZE.
I prefer to keep the current 'ANALYZE' definition, i.e. collecting both
row counts and timing data (which is what 99% of people wants anyway),
and an option to disable the timing.
And the BUFFERS option currently works exactly like that, so defining
ROWS the way you proposed would be inconsistent with the current behavior.
Sure, we could redefine BUFFERS as a subset, so you could do
EXPLAIN (ROWS) ... instead of ... EXPLAIN (ANALYZE, TIMING off) EXPLAIN (BUFFERS) ... instead of ... EXPLAIN (ANALYZE,
BUFFERSon)
but what if someone wants both at the same time? Maybe he could do
EXPLAIN (ROWS, BUFFERS)
and treat that as a union of those subsets. I don't think it's worth it.
I surely can live with both solutions (mine or the one you proposed).
kind regards
Tomas