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