Re: Parallel Seq Scan vs kernel read ahead

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Parallel Seq Scan vs kernel read ahead
Дата
Msg-id CAEudQAraz5Aj7hUR91z1Qmqxwu8rq_Kn+syYEL71S06AFxsyng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan vs kernel read ahead  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Parallel Seq Scan vs kernel read ahead  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Em qua., 20 de mai. de 2020 às 21:03, Thomas Munro <thomas.munro@gmail.com> escreveu:
On Thu, May 21, 2020 at 11:51 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
> Em qua., 20 de mai. de 2020 às 20:48, Thomas Munro <thomas.munro@gmail.com> escreveu:
>> On Thu, May 21, 2020 at 11:15 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
>> > postgres=# set max_parallel_workers_per_gather = 0;
>> > Time: 227238,445 ms (03:47,238)
>> > postgres=# set max_parallel_workers_per_gather = 1;
>> > Time: 138027,351 ms (02:18,027)
>>
>> Ok, so it looks like NT/NTFS isn't suffering from this problem.
>> Thanks for testing!
>
> Maybe it wasn’t clear, the tests were done with your patch applied.

Oh!  And how do the times look without it?
Vanila Postgres (latest)

create table t as select generate_series(1, 800000000)::int i;
 set max_parallel_workers_per_gather = 0;
Time: 210524,317 ms (03:30,524)
set max_parallel_workers_per_gather = 1;
Time: 146982,737 ms (02:26,983)

regards,
Ranier Vilela

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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Expand the use of check_canonical_path() for more GUCs
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Subplan result caching