Re: SeqScan costs - Mailing list pgsql-hackers

From Zeugswetter Andreas OSB sIT
Subject Re: SeqScan costs
Date
Msg-id 6DAFE8F5425AB84DB3FCA4537D829A561CD1C3AD19@M0164.s-mxs.net
Whole thread Raw
In response to Re: SeqScan costs  (Simon Riggs <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Transaction-controlled robustness for replication
Next
From: Decibel!
Date:
Subject: Re: temporary statistics option at initdb time