Received: from localhost (maia-4.hub.org [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 4A1579FBB2B
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 19:01:45 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 61815-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 19:01:42 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 81AE49FBA5E
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Apr 2007 19:01:42 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3CM1fg7009214;
	Thu, 12 Apr 2007 18:01:41 -0400 (EDT)
To: Steve <cheetah@tanabi.org>
cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Strangely Variable Query Performance 
In-reply-to: <Pine.GSO.4.64.0704121735000.17955@kittyhawk.tanabi.org> 
References: <57271CC2-BCB1-4ACA-A177-4FF64F1BC33F@brandeis.edu>
	<E1HbzJr-0005VG-GC@elasmtp-curtail.atl.sa.earthlink.net>
	<16E9A17C-ADFA-43B2-B7EA-5C7A4D7E96D1@event-s.net>
	<E1Hc0lc-0001iE-La@elasmtp-banded.atl.sa.earthlink.net>
	<0914C05F-BA1B-4A6C-A1B1-52256BC851A4@event-s.net>
	<1176396964.13754.16.camel@state.g2switchworks.com>
	<Pine.LNX.4.64.0704121000570.32187@glacier.frostconsultingllc.com>
	<Pine.GSO.4.64.0704121653030.17955@kittyhawk.tanabi.org>
	<5772.1176413092@sss.pgh.pa.us>
	<Pine.GSO.4.64.0704121735000.17955@kittyhawk.tanabi.org>
Comments: In-reply-to Steve <cheetah@tanabi.org>
	message dated "Thu, 12 Apr 2007 17:40:28 -0400"
Date: Thu, 12 Apr 2007 18:01:41 -0400
Message-ID: <9213.1176415301@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/266
X-Sequence-Number: 24143

Steve <cheetah@tanabi.org> writes:
> Here's the table and it's indexes.  Before looking, a note; there's 
> several 'revop' indexes, this is for sorting.  The customer insisted on, 
> frankly, meaninglessly complicated sorts.  I don't think any of that 
> matters for our purposes here though :)

Oy vey ... I hope this is a read-mostly table, because having that many
indexes has got to be killing your insert/update performance.

I see that some of the revop indexes might be considered relevant to
this query, so how exactly have you got those opclasses defined?
There's built-in support for reverse sort as of CVS HEAD, but in
existing releases you must have cobbled something together, and I wonder
if that could be a contributing factor ...

			regards, tom lane