Re: Parallel Seq Scan vs kernel read ahead

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Parallel Seq Scan vs kernel read ahead
Дата
Msg-id CAApHDvqdowju9Rp+d6xNxt_dvo1m31k1=QBaB8WAd8S8Lkvx3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan vs kernel read ahead  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Parallel Seq Scan vs kernel read ahead  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Parallel Seq Scan vs kernel read ahead  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 11 Jun 2020 at 23:35, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Another point I am thinking is that whatever formula we come up here
> might not be a good fit for every case.  For ex. as you mentioned
> above that larger step-size can impact the performance based on
> qualification, similarly there could be other things like having a
> target list or qual having some function which takes more time for
> certain tuples and lesser for others especially if function evaluation
> is based on some column values.  So, can we think of providing a
> rel_option for step-size?

I think someone at some point is not going to like the automatic
choice. So perhaps a reloption to allow users to overwrite it is a
good idea. -1 should most likely mean use the automatic choice based
on relation size.  I think for parallel seq scans that filter a large
portion of the records most likely need some sort of index, but there
are perhaps some genuine cases for not having one. e.g perhaps the
query is just not run often enough for an index to be worthwhile. In
that case, the performance is likely less critical, but at least the
reloption would allow users to get the old behaviour.

David



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: extensible options syntax for replication parser?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Recording test runtimes with the buildfarm