Re: [HACKERS] Parallel Index Scans

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Parallel Index Scans
Дата
Msg-id CA+TgmoZqyK8a3LfMuRBX+nKQ2u6OOUYkAuJupNnarYYcuANenw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Parallel Index Scans  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Parallel Index Scans  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Fixed.

I think that the whole idea of GatherSupportsBackwardScan is wrong.
Gather doesn't support a backwards scan under any circumstances,
whether the underlying node does or not.  You can read the tuples
once, in order, and you can't back up.  That's what supporting a
backward scan means: you can back up and then move forward again.
It's there to support cursor operations.

Also note this comment in ExecSupportsBackwardsScan, which seems just
as relevant to parallel index scans as anything else:
   /*    * Parallel-aware nodes return a subset of the tuples in each worker, and    * in general we can't expect to
haveenough bookkeeping state to know    * which ones we returned in this worker as opposed to some other worker.    */
if (node->parallel_aware)       return false;
 

If all of that were no issue, the considerations in
TargetListSupportsBackwardScan could be a problem, too.  But I think
there shouldn't be any issue having Gather just continue to return
false.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Dmitry Fedin
Дата:
Сообщение: [HACKERS] [PATCH] Change missleading comment for tm_mon field of pg_tm structure