Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> sfunc is called once for each input row. Unlike with normal aggregates, sfunc
> is passed the whole input row, so that e.g RANK can compare it against the
> previous row, or LEAD can buffer it.
I'm not sure I follow this bit about being passed the whole input row. How
would that relate to something like lag(x*y, 2) for example?
> outfunc is a set-returning function, and it is called until it returns no more
> rows, after each sfunc invocation.
And in any case I feel like this is abstraction on the cheap. The only reason
it's so general is because it's leaving all the work to the functions to
implement.
It also means we get no benefit from cases like
SELECT lag(x,5),lag(y,5),lag(z,5)
where the executor could keep one tuplestore and for all of them. For that
matter it could keep one tuplestore even for cases like lag(x,5),lag(y,4).
What would the executor do for a query like
SELECT lead(x,1),lead(y,2),lead(y,3)
It would not only have to keep a tuplestore to buffer the output but it would
have to deal with receiving data from different SRFs at different times. The
best approach I can think of would be to keep a tuplestore for each SRF using
themas queues, reading old values from the head as soon as they all have at
least one new value in them.
And it doesn't answer how to deal with things like
SELECT lag(x,1) OVER (ORDER BY a), lag(x,1) OVER (ORDER BY b)
I, uh, don't actually have any ideas of how to deal with that one :(
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
