Skip site navigation (1) Skip section navigation (2)

Re: Common Table Expressions (WITH RECURSIVE) patch

From: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
To: "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <stark(at)enterprisedb(dot)com>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Tatsuo Ishii" <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-10-02 12:13:44
Message-ID: e08cc0400810020513s735936b3kfd74e73f1675b3fb@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2008/10/2 Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>:
>
>
> On 2 Oct 2008, at 05:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-02 12:27:47
Subject: Re: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.
Previous:From: Peter EisentrautDate: 2008-10-02 11:51:08
Subject: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group