Re: Parallel Seq Scan

> On Tue, Sep 22, 2015 at 9:12 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > Oh... I did exactly duplicated job a few days before.
> >
> https://github.com/kaigai/sepgsql/blob/readfuncs/src/backend/nodes/readfuncs
> .c
>
> Please post the patch here, and clarify that it is under the PostgreSQL license.
>
Of course. I intend to submit.

> > Regarding of CustomScan node, I'd like to run on worker process as soon as
> > possible once it gets supported. I'm highly motivated.
>
> Great.
>
> > Andres raised a related topic a few weeks before:
> >
> http://www.postgresql.org/message-id/20150825181933.GA19326@awork2.anarazel.
> de
> >
> > Here are two issues:
> >
> > * How to reproduce "methods" pointer on another process. Extension may not be
> > loaded via shared_preload_libraries.
>
> The parallel mode stuff already has code to make sure that the same
> libraries that were loaded in the original backend get loaded in the
> new one. But that's not going to make the same pointer valid there.
>
> > -> One solution is to provide a pair of library and symbol name of the method
> > table, instead of the pointer. I think it is a reasonable idea.
>
> I agree.
>
> > * How to treat additional output of TextOutCustomScan.
> > -> Here are two solutions. (1) Mark TextOutCustomScan as an obsolete callback,
> > however, it still makes Andres concern because we need to form/deform private
> > data for copyObject safe. (2) Add TextReadCustomScan (and
> NodeEqualCustomScan?)
> > callback to process private fields.
>
> I don't see how making it obsolete solves anything. Any node that
> wants to run in a worker needs to have outfuncs and readfuncs support.
>
In actually, I'm inclined to the (2) rather than (1).
In case of (2), we shall need two new callbacks on _copyCustomScan and
_readCustomScan. I'll try to make up.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>