Re: Choice of bitmap scan over index scan

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <mathieu(at)dezutter(dot)org>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Choice of bitmap scan over index scan
Date: 2010-01-10 15:53:51
Message-ID: 4B49A3AF020000250002E138@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Mathieu De Zutter wrote:

> Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz
> 2GB RAM
> 2x500GB RAID-1

> Running Debian/Etch AMD64
> PG version: PostgreSQL 8.3.8 on x86_64

> Server also runs DNS/Mail/Web/VCS/... for budget reasons.
> Database size is 1-2 GB. Also running copies of it for testing/dev.

I would try something like this and see how it goes:

shared_buffers = 200MB
work_mem = 32MB
effective_cache_size = 1.2GB
seq_page_cost = 0.1
random_page_cost = 0.1

Some of these settings require a PostgreSQL restart.

I may have gone too aggressively low on the page costs, but it seems
likely with a "1-2 GB" database and 2 GB RAM, the active portions of
your database will be fully cached in spite of the other
applications. Besides looking at the impact on this one query, you
should keep an eye on all queries after such changes, and post for
any which become unacceptably slow. Properly tuning something like
this can take a few iterations.

-Kevin

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-01-10 16:01:42 Re: Choice of bitmap scan over index scan
Previous Message Mathieu De Zutter 2010-01-10 15:43:40 Re: Choice of bitmap scan over index scan