Re: introduction of WIP window function patch

2008/7/6 Simon Riggs <simon@2ndquadrant.com>:
>
> 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