Re: SeqScan costs

From: Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SeqScan costs
Date: 2008-08-13 15:42:24
Message-ID: 6DAFE8F5425AB84DB3FCA4537D829A561CD1C3AD19@M0164.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2008-08-13 16:09:53 Re: benchmark farm
Previous Message Decibel! 2008-08-13 15:30:30 Re: temporary statistics option at initdb time