Re: Window Functions: buffering strategy

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Window Functions: buffering strategy
Date: 2008-10-20 14:51:51
Message-ID: 48FC9B07.6080409@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hitoshi Harada wrote:
> Hi,
>
> 2008/10/20 Simon Riggs <simon(at)2ndquadrant(dot)com>:
>> On Mon, 2008-10-20 at 10:32 +0900, Hitoshi Harada wrote:
>>
>>> So I propose three Window node buffering strategies,
>>> row/frame/partition buffering so as to avoid unnecessary row
>>> buffering.
>> Sounds good from here. Can I suggest you release the code in phases?
>>
>> It would be better if we got just one of those done (row?), than to
>> attempt all 3 and end up with none because of emerging details.
>
> Thank you for your feedback.
> Ok, actually the first will be partition buffering, because it covers
> all of the functions' requirement. The row buffering is kind of
> optimization in the special case.

The thought I had during the last commit fest was that the function
would call a callback, something like window_forget(pos), that would
tell the system that it can release any rows before the given position.
That way you only need one method, and it's also be optimal for
functions like lag(), that doesn't fit perfectly into either the row or
frame buffering category. Or do we need the information at plan-time?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-10-20 14:51:54 Re: minimal update
Previous Message Peter Eisentraut 2008-10-20 14:50:03 Re: crypt auth