Re: Parallel Seq Scan
От | Amit Kapila |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CAA4eK1KUoOb8C8L-+bajLhBitePRRxGNZOjVFaVndsOR4tZNdA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Wed, Jul 1, 2015 at 1:21 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Wed, 2015-07-01 at 11:07 +0530, Amit Kapila wrote:
>
> > For what you are asking to change name for?
>
> There are still some places, at least in the comments, that call it a
> parallel sequential scan.
>
>
> > a. Infrastructure for parallel execution, like some of the stuff in
> > execparallel.c, heapam.c,tqueue.c, etc and all other generic
> > (non-nodes specific) code.
>
> Did you consider passing tuples through the tqueue by reference rather
> than copying? The page should be pinned by the worker process, but
> perhaps that's a bad assumption to make?
>
>
> On Wed, 2015-07-01 at 11:07 +0530, Amit Kapila wrote:
>
> > For what you are asking to change name for?
>
> There are still some places, at least in the comments, that call it a
> parallel sequential scan.
>
In the initial version of patch, there was only one node parallel seqscan
node and the occurrences you are seeing are left over's, I will change
them in next patch.
>
> > a. Infrastructure for parallel execution, like some of the stuff in
> > execparallel.c, heapam.c,tqueue.c, etc and all other generic
> > (non-nodes specific) code.
>
> Did you consider passing tuples through the tqueue by reference rather
> than copying? The page should be pinned by the worker process, but
> perhaps that's a bad assumption to make?
>
Yes, IIRC there was some discussion happened and I haven't used for
the reason you mentioned. It doesn't same sane to hold the pin on
page for long time (we need to retain the pin till master backend processes
В списке pgsql-hackers по дате отправления: