Re: reducing random_page_cost from 4 to 2 to force index scan - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: reducing random_page_cost from 4 to 2 to force index scan
Date
Msg-id 4DB6F4BB020000250003CEB9@gw.wicourts.gov
Whole thread Raw
In response to reducing random_page_cost from 4 to 2 to force index scan  (Sok Ann Yap <sokann@gmail.com>)
Responses Re: reducing random_page_cost from 4 to 2 to force index scan  (Merlin Moncure <mmoncure@gmail.com>)
Re: reducing random_page_cost from 4 to 2 to force index scan  (Sok Ann Yap <sokann@gmail.com>)
List pgsql-performance
Sok Ann Yap <sokann@gmail.com> wrote:

> So, index scan wins by a very small margin over sequential scan
> after the tuning. I am a bit puzzled because index scan is more
> than 3000 times faster in this case, but the estimated costs are
> about the same. Did I do something wrong?

Tuning is generally needed to get best performance from PostgreSQL.
Needing to reduce random_page_cost is not unusual in situations
where a good portion of the active data is in cache (between
shared_buffers and the OS cache).  Please show us your overall
configuration and give a description of the hardware (how many of
what kind of cores, how much RAM, what sort of storage system).  The
configuration part can be obtained by running the query on this page
and pasting the result into your next post:

http://wiki.postgresql.org/wiki/Server_Configuration

There are probably some other configuration adjustments you could do
to ensure that good plans are chosen.

-Kevin

pgsql-performance by date:

Previous
From: Sok Ann Yap
Date:
Subject: reducing random_page_cost from 4 to 2 to force index scan
Next
From: Merlin Moncure
Date:
Subject: Re: reducing random_page_cost from 4 to 2 to force index scan