Re: Why percent_rank is so slower than rank? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why percent_rank is so slower than rank?
Date
Msg-id 26548.1292004419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why percent_rank is so slower than rank?  (Hitoshi Harada <umi.tanuki@gmail.com>)
List pgsql-hackers
Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 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?

Giving back the memory as we do the scan is still a good thing IMO;
there might be other uses for it.  In any case I don't see where you're
going to put such a heuristic without breaking potentially interesting
uses elsewhere.  The tuplestore doesn't know anything about partitions
being read to the end; and WindowAgg doesn't (or shouldn't) know about
whether the tuplestore is all in memory.

Furthermore, the performance problem would exist for any situation where
the window functions had read far beyond the frame start, whether that
was all the way to partition end or not.  Consider a frame like ROWS
BETWEEN 10000 PRECEDING AND 10000 FOLLOWING.

In the end this is a local problem inside tuplestore, and kluging its
callers to work around it is the wrong approach.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: initdb failure with Postgres 8.4.4
Next
From: Robert Haas
Date:
Subject: Re: Extensions, patch v16