Re: Slow index - Mailing list pgsql-performance

From Matthew Wakeling
Subject Re: Slow index
Date
Msg-id alpine.DEB.1.10.0809251416390.19066@aragorn.flymine.org
Whole thread Raw
In response to Re: Slow index  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Thu, 25 Sep 2008, Tom Lane wrote:
> Matthew Wakeling <matthew@flymine.org> writes:
>> Hi all. I'm having an interesting time performance-wise with a set of indexes.
>> Any clues as to what is going on or tips to fix it would be appreciated.
>
> Are the indexed columns all the same datatype?  (And which type is it?)

Gene.key_primaryidentifier is a text column
Gene.key_secondaryidentifier is a text column followed by an integer
OntologyTerm.key_name_ontology is a text column followed by an integer
Protein.key_primaryacc is a text column
Publication.key_pubmed is a text column
Synonym.key_synonym is an integer, two texts, and an integer

In most cases, the first text will be enough to uniquely identify the
relevant row.

> It might be helpful to REINDEX the "slow" index.  It's possible that
> what you're seeing is the result of a chance imbalance in the btree,
> which reindexing would fix.

That's unlikely to be the problem. When the application starts, the
database has just been loaded from a dump, so the indexes are completely
fresh. The behaviour starts out bad, and does not get progressively worse.

I don't know - is there likely to be any locking getting in the way? Our
write traffic is fairly large chunks of binary COPY in. Could it be
locking the index while it adds the write traffic to it?

Matthew

--
Most books now say our sun is a star. But it still knows how to change
back into a sun in the daytime.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Slow index
Next
From: John Huttley
Date:
Subject: Slow updates, poor IO