Re: Tuning to speed select

From: Reece Hart <reece(at)harts(dot)net>
To: Tom Laudeman <twl8n(at)virginia(dot)edu>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Tuning to speed select
Date: 2006-08-09 22:13:25
Message-ID: 1155161605.3808.224.camel@tallac.gene.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2006-08-09 at 16:54 -0400, Tom Laudeman wrote:

> Great suggestion. I've read about CLUSTER, but never had a chance to
> use it. The only problem is that this table with 9 million records has
> 5 or 6 indexes. It is hard to pick the most used, but I'll bet CLUSTER
> will make at least one of the queries run very fast, especially for an
> index with a small number of distinct values.

Tom-

I found multi-column indexes and clustering to be extremely beneficial
in 7.4. I still use them in 8.1, but I haven't compared them extensively
with equivalent queries that use bitmap index scans. The obvious
downside of having more indexes is the additional time and space
overhead during insert, update, or delete.

The approach I took to design multi-column indexes was to run explain on
representative queries and look for seq scans. The seq scans indicate
which columns /might/ be well-served by indexes. In 7.4, the order of
indexed columns was important. (I saw something in the 8.1 release notes
that made me think that this was no longer true, but I haven't verified
that.)

-Reece

--
Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2006-08-09 22:16:11 Re: PITR timeline question
Previous Message Tom Lane 2006-08-09 21:44:04 Re: [GENERAL] WIN32 Build?