Hitoshi Harada wrote:
The real problem is not how to cut off preceding rows, but how to read ahead after the current row. I intend to avoid reading ahead until end of the partition for only row_number() that doesn't need any following rows. Sometimes we have to store whole the partition before returning the first result and sometimes not. It depends on function categories, or function access range. My current idea is classify Window function API to three parallel to buffering strategies.
Could the rows be read ahead on demand? If the window function calls window_getarg on a row that's not yet fetched, fetch forward to that row.
And the lag()/lead(), spec says "OFFSET is exact numeric literal" but we postgres doesn't have mechanism to limit the function argument data type to Const integer only. So I am thinking about OFFSET for lag()/lead() may be dynamic integer variable. If it comes, even those functions don't know how many rows should be cut off. The lag()/lead() can access any row of partition, per spec.
Hmm, yeah, that's a bit of a problem :-(. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
