Re: How is random_page_cost=4 ok?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Nikolas Everett <nik9000(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How is random_page_cost=4 ok?
Date: 2008-10-15 00:38:47
Message-ID: 200810150038.m9F0clb07585@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nikolas Everett wrote:
> >
> > In any case your experience doesn't match mine. On a machine with a sizable
> > raid controller setting random_page_cost higher does generate, as expected,
> > plans with more bitmap heap scans which are in fact faster.
> >
>
> We're running postgres backed by a NetApp 3020 via fiber and have had a lot
> of success setting random page cost very high (10). Sequential reads are
> just that much faster. I'm not sure if thats because we've configured
> something wrong or what, but thats a really useful knob for us.

One other issue is that sequential I/O for data that is mostly random is
going to wipe more of the buffer cache than random access, so there
should perhaps be some additional cost associated with sequential access
to bias toward random access. Not sure how our new code that prevents
large table scans from wiping the cache affect this.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-15 00:47:22 Re: Column level triggers
Previous Message Andrew Dunstan 2008-10-15 00:29:28 Re: minimal update