Re: Why percent_rank is so slower than rank?

2010/12/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
>> I see it's too late now that you've committed it,
>
> Patches can always be reverted...
>
>> but it seems there
>> was another way to avoid it by not trimming from percent_rank()
>> individually. Once the whole partition is fit to the memory, you don't
>> need to trim it since it never grows. The trimming logic is for
>> something like moving aggregates and (simple) rank(), which grows
>> tuplestore content as it advances. percent_rank() doesn't seem to
>> match the optimization.
>
> I don't think this idea leads to a robust solution.  When you have a
> combination of different window functions being used in the same scan,
> you can't expect any one of them to know the global situation.  Having
> percent_rank lie about its requirements in order to avoid bad behavior
> in the tuplestore infrastructure is just going to create more problems
> down the road.  We need to have the individual functions tell the truth
> and then do any optimization hacking in the WindowAgg code or
> infrastructure.

Hm? Once percent_rank() scans to the partition end, any other window
functions that scans row by row don't need to care the memory
reduction, aren't they? Or more generally, if the partition was
scanned to the end, we don't need to trim tuplestore anymore. Am I
misunderstanding?

Regards,

--
Hitoshi Harada