From: | "Greg Stark" <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hitoshi Harada" <umi(dot)tanuki(at)gmail(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-01 14:03:37 |
Message-ID: | 4136ffa0810010703t1f7960a8y1a21f2fead1e79a3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So it seems like the appropriate generalization is to have an array of
> read positions inside the tuplestore and allow callers to say "read
> using position N", plus some API to allow positions to be allocated to
> different requestors. We could get rid of the separate mark pointer by
> implementing an API that allows position X to be copied to position Y.
> But the actual value of a position (a tuple number or file position
> info) would never be exposed to callers.
That's basicaly what had done (though i had n "readers" which
encapsulated the current pointer and mark).
One other reason the tuplestore should know the position of all the
readers is that ideally it would want to be able to discard any tuples
older than the oldest read position. That also means it needs to know
when all the call sites have allocated their position and don't need
to reset it.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Hurt | 2008-10-01 14:05:33 | Re: Block-level CRC checks |
Previous Message | Brian Hurt | 2008-10-01 13:55:55 | Re: Block-level CRC checks |