Re: How to estimate the shared memory size required for parallel scan? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: How to estimate the shared memory size required for parallel scan?
Date
Msg-id CAEepm=1_hnxj8L3+fH6_BrU8F19A6Q9MyV5pRG1BX18aW6GGGw@mail.gmail.com
Whole thread Raw
In response to Re: How to estimate the shared memory size required for parallel scan?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: How to estimate the shared memory size required for parallel scan?
List pgsql-hackers
On Sun, Aug 19, 2018 at 1:40 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> A true parallel scan of an FDW would be one where each process emits
> an arbitrary fraction of the tuples, but together they emit all of the
> tuples.  You'd almost certainly need to use some shared memory to
> coordinate that.  To say that you support that, I think your
> GetForeignPaths() function would need to call add_partial_path().  And
> unless I'm mistaken, whether or not InitializeDSMForeignScan etc are
> called might be the only indication you get of whether you need to run
> in parallel-aware mode.  I haven't personally heard of any FDWs that
> can do this yet, but I just tried hacking file_fdw to register a
> partial path and it seems to work (though of course the results are
> duplicated because the emitted tuples are not actually partial).

... though I just noticed that my quick test used "Single Copy" mode.
I think I see why: it looks like core's create_foreignscan_path()
function might need to take num_workers and set parallel_aware if > 0.
So I guess this hasn't been done before and would require some more
research.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: How to estimate the shared memory size required for parallel scan?
Next
From: Andres Freund
Date:
Subject: Re: TupleTableSlot abstraction