Re: Help w/speeding up range queries?

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: "Weslee Bilodeau" <weslee(dot)bilodeau(at)hypermediasystems(dot)com>, "John Major" <major(at)cbio(dot)mskcc(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Help w/speeding up range queries?
Date: 2006-11-01 00:10:54
Message-ID: C16D260E.5940%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Weslee,

On 10/31/06 3:57 PM, "Weslee Bilodeau"
<weslee(dot)bilodeau(at)hypermediasystems(dot)com> wrote:

> Basic question - What version, and what indexes do you have?

I'd expect the problem with this is that unless the indexed column is
correlated with the loading order of the rows over time, then the index will
refer to rows distributed non-sequentially on disk, in which case the index
can be worse than a sequential scan.

You can cluster the table on the index (don't use the "CLUSTER" command! Do
a CREATE TABLE AS SELECT .. ORDER BY instead!), but the index won't refer to
sequential table data when there's more data added. What this does is
analogous to the partitioning option though, and you don't have the problem
of the table being de-clustered on the constraint column.

The problem with the current support for partitioning is that you have to
implement rules for inserts/updates/deletes so that you can do them to the
parent and they will be implemented on the children. As a result,
partitioning is not transparent. OTOH, it achieves great performance gains.

BTW - If you have a date column and your data is loaded in date order, then
an index is all that's necessary, you will get sequential access.

- Luke

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message mark 2006-11-01 00:20:26 Re: MVCC & indexes?
Previous Message Weslee Bilodeau 2006-10-31 23:57:04 Re: Help w/speeding up range queries?