2008/7/6 Simon Riggs <[EMAIL PROTECTED]>: > > On Sun, 2008-07-06 at 17:39 +0900, H.Harada wrote: > >> Is there security/performance issue about this? > > Performance, yes. > > If we need access to more rows than will fit within work_mem we have a > problem and will need to restart sort. Giving random access to all > tuples in the current window, whatever its size would be very costly, > which is why we have optimized that access for merge joins. So we need > to know how far back access is required, if any - think of that as an > "access window" definition.
Is this about tuplesort, not tuplestore? At a glance, tuplestore seems to be able to access tuples randomly without any performance problem, just fitting its pointer. So I thought planner should always insert Sort node before Window node to let Window not to sort, as I explained in the document. But anyways, I understand some kind of optimization mechanism to scroll in/out window is needed. > I know I rattle on about performance, but with window functions it will > be critical to their usability to have them perform well. We can already > do the types of analysis that window functions allow, it just requires > hand written procedures to do it. So the window functions must perform > acceptably well against very large tables (i.e. much bigger than > memory). I know, the probable use case is against large data set. There's no reason to add this feature if it is slower than self joins or other kludge methods. -- 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