Re: Why percent_rank is so slower than rank?

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.

regards, tom lane