2008/11/26 Heikki Linnakangas <[EMAIL PROTECTED]>: > Hitoshi Harada wrote: >> >> I read more, and your spooling approach seems flexible for both now >> and the furture. Looking at only current release, the frame with ORDER >> BY is done by detecting peers in WinFrameGetArg() and add row number >> of peers to winobj->currentpos. Actually if we have capability to >> spool all rows we need on demand, the frame would be only a boundary >> problem. > > Yeah, we could do that. I'm afraid it would be pretty slow, though, if > there's a lot of peers. That could probably be alleviated with some sort of > caching, though.
I added code for this issue. See http://git.postgresql.org/?p=~davidfetter/window_functions/.git;a=blobdiff;f=src/backend/executor/nodeWindow.c;h=f2144bf73a94829cd7a306c28064fa5454f8d369;hp=50a6d6ca4a26cd4854c445364395ed183b61f831;hb=895f1e615352dfc733643a701d1da3de7f91344b;hpb=843e34f341f0e824fd2cc0f909079ad943e3815b This process is very similar to your aggregatedupto in window aggregate, so they might be shared as general "the way to detect frame boundary", aren't they? I am randomly trying some issues instead of agg common code (which I now doubt if it's worth sharing the code), so tell me if you're restarting your hack again. I'll send the whole patch. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
