Re: Parallel Seq Scan vs kernel read ahead

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Parallel Seq Scan vs kernel read ahead
Дата
Msg-id CAEudQAqAOaQ48+BCvz4mEyL4Mm9dMiN5Rsa7vGME2-YpbMJTpA@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 00:09, Thomas Munro <thomas.munro@gmail.com> escreveu:
On Wed, May 20, 2020 at 2:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> Good experiment.  IIRC, we have discussed a similar idea during the
> development of this feature but we haven't seen any better results by
> allocating in ranges on the systems we have tried.  So, we want with
> the current approach which is more granular and seems to allow better
> parallelism.  I feel we need to ensure that we don't regress
> parallelism in existing cases, otherwise, the idea sounds promising to
> me.

Yeah, Linux seems to do pretty well at least with smallish numbers of
workers, and when you use large numbers you can probably tune your way
out of the problem.  ZFS seems to do fine.  I wonder how well the
other OSes cope.
Windows 10 (64bits, i5, 8GB, SSD)

postgres=# set max_parallel_workers_per_gather = 0;
SET
Time: 2,537 ms
postgres=#  select count(*) from t;
   count
-----------
 200000000
(1 row)


Time: 47767,916 ms (00:47,768)
postgres=# set max_parallel_workers_per_gather = 1;
SET
Time: 4,889 ms
postgres=#  select count(*) from t;
   count
-----------
 200000000
(1 row)


Time: 32645,448 ms (00:32,645)

How display " -> execution time 5.2s, average read size ="?

regards,
Ranier VIlela

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Optimizer docs typos
Следующее
От: Jürgen Purtz
Дата:
Сообщение: Re: Add A Glossary