Skip site navigation (1) Skip section navigation (2)

Re: large tables and simple "= constant" queries using indexes

From: Matthew <matthew(at)flymine(dot)org>
To: Pgsql-Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: large tables and simple "= constant" queries using indexes
Date: 2008-04-10 09:51:13
Message-ID: Pine.LNX.4.64.0804101042050.20402@aragorn.flymine.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 10 Apr 2008, PFC wrote:

... Lots of useful advice ...

> 	- If you often query rows with the same gene_ref, consider using 
> CLUSTER to physically group those rows on disk. This way you can get all rows 
> with the same gene_ref in 1 seek instead of 2000. Clustered tables also make 
> Bitmap scan happy.

In my opinion this is the one that will make the most difference. You will 
need to run:

CLUSTER gene_prediction_view USING gene_prediction_view_gene_ref_key;

after you insert significant amounts of data into the table. This 
re-orders the table according to the index, but new data is always written 
out of order, so after adding lots more data the table will need to be 
re-clustered again.

> - Switch to a RAID10 (4 times the IOs per second, however zero gain if 
> you're single-threaded, but massive gain when concurrent)

Greg Stark has a patch in the pipeline that will change this, for bitmap 
index scans, by using fadvise(), so a single thread can utilise multiple 
discs in a RAID array.

Matthew

-- 
Prolog doesn't have enough parentheses. -- Computer Science Lecturer

In response to

Responses

pgsql-performance by date

Next:From: Gaetano MendolaDate: 2008-04-10 12:39:28
Subject: shared_buffers in 8.2.x
Previous:From: Richard HuxtonDate: 2008-04-10 08:46:09
Subject: Re: varchar index joins not working?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group