From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | "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 04:44:45 |
Message-ID: | 14004.1222922685@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2008/10/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Okay, there's a patch in CVS HEAD that works this way. Let me know if
>> it needs further tweaking for your purposes.
> 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.
The scheme that I have in mind here is that you keep (at least) two read
pointers, one that is where you're actually reading the data and one
that is nailing down the oldest point you might need to return to.
This is a generalization of the previous mark/restore logic to allow any
number of pairs of mark and restore points.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-02 05:14:05 | Re: pgsql: Allow pg_regress to be run outside the build tree. |
Previous Message | Andrew Dunstan | 2008-10-02 01:25:09 | Re: Fwd: Has anyone built pgbash-7.3 against postgreSQL-8.3? |