Re: Common Table Expressions (WITH RECURSIVE) patch

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

In response to

Responses

Browse pgsql-hackers by date

  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