Re: How is random_page_cost=4 ok?

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> ... So the true random/sequential ratio
> reaches crazy numbers.

Bear in mind that seq_page_cost and random_page_cost are intended to
represent the time to read *and process* a page, so there's some CPU
component involved there, and this limits the ratio that could be
reached in practice.

In particular, if the OS lays out successive file pages in a way that
provides zero latency between logically adjacent blocks, I'd bet a good
bit that a Postgres seqscan would miss the read timing every time, and
degrade to handling about one block per disk rotation. Those 100MB/s
numbers are just mirages as far as seqscan speed goes.

regards, tom lane