On Mar5, 2014, at 18:27 , Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 5 March 2014 14:35, Florian Pflug <fgp@phlo.org> wrote:
>> When I added the EXPLAIN stuff, I initially simply reported the number
>> of times nodeWindowAgg has to restart the aggregation. The problem with
>> that approach is that not all restarts carry the same cost. If the frames
>> either don't overlap at all or are identical, restarts don't cause any
>> additional work. And for fixed-length frames (BETWEEN n PRECEEDING AND
>> m FOLLOWING), the performance effects of restarts depends on m-n.
>>
>> Which is why I made it count the number of aggregated input rows instead.
>>
>> Having said that, I' not really 100% happy with the name
>> "Transitions Per Row" for this - it was simply the best I could come up with
>> that was reasonably short. And I'm certainly open to reporting the absolute
>> count instead of a factor relative to ntuples.
>>
>> If we made it an absolute count, would calling this "Aggregated Rows" work
>> for you?
>
> I'm not sure about naming, but I think my preference would be to
> output the correct absolute counts for both the forward and inverse
> transitions (i.e. multiply by the right combinations of numaggs and
> numaggs_restart). The EXPLAIN output already tells you how many
> aggregates there are, and how many rows there are, so you'd be able to
> work out from that how much extra work it's doing.
Hm, if we do that we might as well go all the way and simply report these
numbers per aggregate, instead of once per window aggregation node. That'd
provide the maximum amount of information, and be quite unambiguous.
best regards,
Florian Pflug