Re: SeqScan costs

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas OSB sIT
Тема Re: SeqScan costs
Дата
Msg-id 6DAFE8F5425AB84DB3FCA4537D829A561CD1C3AD19@M0164.s-mxs.net
обсуждение исходный текст
Ответ на Re: SeqScan costs  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
> > > Proposal: Make the first block of a seq scan cost random_page_cost, then
> > > after that every additional block costs seq_page_cost.

+1

> AFAICS the cost cross-over is much higher than the actual elapsed time
> cross-over for both narrow and wide tables.

Which makes absolute sense, since readahead can only reduce cost when you
read more than one page (and more than a few when lacking fadvise tech).

I am wondering about your test though. It was all cached, so it seems
we also underestimate the CPU cost of accessing and comparing all the rows
during seq scan.

> Thats why using SET enable_seqscan=off helps performance in many cases,
> or why people reduce random_page_cost to force index selection.

Sequential scans that cause more IO than an alternate index path are often
counter productive in highly concurrent scenarios.
In such scenarios it is really reasonable to lower random_page_cost.

Andreas


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Transaction-controlled robustness for replication
Следующее
От: Decibel!
Дата:
Сообщение: Re: temporary statistics option at initdb time