Support tid range scan in parallel?

Поиск
Список
Период
Сортировка
От Cary Huang
Тема Support tid range scan in parallel?
Дата
Msg-id 18f2c002a24.11bc2ab825151706.3749144144619388582@highgo.ca
обсуждение исходный текст
Ответы Re: Support tid range scan in parallel?  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers

Hello

 

When using ctid as a restriction clause with lower and upper bounds, PostgreSQL's planner will use TID range scan plan to handle such query. This works and generally fine. However, if the ctid range covers a huge amount of data, the planner will not use parallel worker to perform ctid range scan because it is not supported. It could, however, still choose to use parallel sequential scan to complete the scan if ti costs less. 

 

In one of our migration scenarios, we rely on tid range scan to migrate huge table from one database to another once the lower and upper ctid bound is determined. With the support of parallel ctid range scan, this process could be done much quicker.

 

The attached patch is my approach to add parallel ctid range scan to PostgreSQL's planner and executor. In my tests, I do see an increase in performance using parallel tid range scan over the single worker tid range scan and it is also faster than parallel sequential scan covering similar ranges. Of course, the table needs to be large enough to reflect the performance increase.

 

below is the timing to complete a select query covering all the records in a simple 2-column table with 40 million records,

 

 - tid range scan takes 10216ms

 - tid range scan with 2 workers takes 7109ms

 - sequential scan with 2 workers takes 8499ms

 

Having the support for parallel ctid range scan is definitely helpful in our migration case, I am sure it could be useful in other cases as well. I am sharing the patch here and if someone could provide a quick feedback or review that would be greatly appreciated.

 

Thank you!

 

Cary Huang
-------------
HighGo Software Inc. (Canada)


Вложения

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: TerminateOtherDBBackends code comments inconsistency.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Internal error codes triggered by tests