On Mon, Mar 6, 2017 at 7:33 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> Recap
> =====
>
> A design goal of parallel tuplesort is that the parallel case be as
> close to possible as the serial case is already. Very little new code
> is needed in tuplesort.c and logtape.c, most of which is about using a
> new lower-level facility which is very well encapsulated. And, even
> buffile.c "unification", the guts of everything, doesn't have many new
> special cases.
>
> So, workers start with "unifiable" BufFiles, which have very little
> difference with conventional temp BufFiles -- they just create
> filenames in a deterministic fashion, making them discoverable to the
> leader process, through a process of unification (plus you have the
> refcount state in shared memory, though very little). In principle,
> workers could decide to not go through with unification long after the
> fact, and close their unifiable temp files without doing anything for
> the leader, and that would be just fine. By the same token, the
> unified BufFile owned by the leader can be extended if needs be, in a
> way that is virtually indistinguishable from just extending the end of
> any other BufFile. logtape.c recycling for future randomAccess cases
> works just the same as before.
I think something like 0007-hj-shared-buf-file-v6.patch from
https://www.postgresql.org/message-id/CAEepm=3g=dMG+84083fkFzLvgMJ7HdhbGB=AeZABNukbZm3hpA@mail.gmail.com
is probably a good approach to this problem. In essence, it dodges
the problem of trying to transfer ownership by making ownership be
common from the beginning. That's what I've been recommending, or
trying to, anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
