From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Date: | 2014-03-06 14:51:57 |
Message-ID: | AC421BCA-838D-4850-A631-1EDC23521BBB@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar5, 2014, at 23:49 , Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> On Mar5, 2014, at 18:37 , Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday users
>>> got of making sense of it?
>
>> The question isn't what the current output means, but whether it's a
>> good metric to report or not.
>
> If you can't agree, then it isn't.
Probably, yes, so let's find something that *is* a good metric.
(BTW, it's not the authors who disagree here. It was me who put the EXPLAIN
feature in, and Dean reviewed it and found it confusing. The original
author David seems to run out of time to work on this, and AFAIK hasn't
weighted in on that particular feature at all)
>> If we don't report anything, then how would a user check whether a query
>> is slow because of O(n^2) behaviour of a windowed aggregate, or because
>> of some other reasons?
>
> [ shrug... ] They can see whether the Window plan node is where the time
> is going. It's not apparent to me that the extra numbers you propose to
> report will edify anybody.
By the same line of reasoning, every metric except execution time is
superfluous. Comparing execution times really is a horrible way to measure
this - not only does it include all kinds of thing that have nothing to do
with the restart behaviour of aggregates, you'd also have to construct a
base-line query first which is guaranteed to not restart.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-03-06 15:00:42 | Re: jsonb and nested hstore |
Previous Message | Andrew Dunstan | 2014-03-06 14:33:18 | Re: jsonb and nested hstore |