"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> It seems to me to share some ideas with the MemoryContext concept: what
>> about a TupstoreContext associated with tuplestore, you get a common default
>> one if you don't register your own, and use
>> tuplestore_gettuple(MyTupstoreContext, ...);
> I'm just working on tuplestore recording multiple positions for my
> window function project. Attached patch is still in progress but seems
> it works in a situation.
> From my work, the setting/getting read position and delegate savig
> positions to the caller will probably have problems, because of memory
> control for saving positions and tuplestore status changing (memory ->
> BufFile). Instead, I decided it'd better that we can indicate the row
> number by integer.
That seems unreasonably inefficient --- it takes lots more file I/O,
and there's really no need for random access, at least not in what I'm
doing.
I looked at the tuplestore code some more, and my idea of allowing
callers to store their current position externally to tuplestore indeed
doesn't work. The problem is that if dumptuples() happens there's no
way to convert an index-based position to a file-based one. The current
code can handle it because it has access to all the positions (the read,
write, and mark pointers) but any positions stored externally wouldn't
get converted.
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.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
