Re: Common Table Expressions (WITH RECURSIVE) patch - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Common Table Expressions (WITH RECURSIVE) patch
Date
Msg-id e08cc0400810020513s735936b3kfd74e73f1675b3fb@mail.gmail.com
Whole thread Raw
In response to Re: Common Table Expressions (WITH RECURSIVE) patch  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
2008/10/2 Greg Stark <greg.stark@enterprisedb.com>:
>
>
> On 2 Oct 2008, at 05:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> "Hitoshi Harada" <umi.tanuki@gmail.com> writes:
>>
>>> Hmm, I've looked over the patch. Logically window functions can access
>>> arbitrary rows that have been stored in a frame. Thus I had thought
>>> tuplestore should hold all the positions and allow arbitrary random
>>> access indicated by integer. Maybe those functionalities can be
>>> abstracted by the window function API itself. For this matter it seems
>>> that you'd better to look at my future patch.
>>
>> Well, the problem with defining it as "arbitrary" random access is that
>> there's no way for the tuplestore to throw away old data.
>
> And that there's no way to make it work if the tuplestore has spilled to
> disk.
>

In my purpose the "old data" can always be indicated by an integer row
position. So the real problem here is how you store all the row
positions for arbitrary random access closer to O(1). Yes, you can go
to certain row by fetching tuples manytimes from a marked row but it's
inefficient. I know my patch sent before is also inefficent. But
essentially the window function needs high cost.

I'll try to process my work with the patch but maybe more work on
tuplestore will be needed after we see the real problem that I don't
see now either.

Regards,



-- 
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.