From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nikolas Everett <nik9000@gmail.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: explain analyze reports that my queries are fast but they run
	very slowly
In-reply-to: 
 <CAPmjWd3S5pf=BTmjY3h9eAS09S5pAmxwa9X2DtMCUKaMrYdveA@mail.gmail.com>
References: 
 <CAPmjWd2XgV9d3zy3zc8L9PJRdoVM720g2zSQWsDKZsJkOqKMjw@mail.gmail.com>
	<17229.1356636060@sss.pgh.pa.us>
	<CAPmjWd3S5pf=BTmjY3h9eAS09S5pAmxwa9X2DtMCUKaMrYdveA@mail.gmail.com>
Comments: In-reply-to Nikolas Everett <nik9000@gmail.com>
	message dated "Thu, 27 Dec 2012 14:28:11 -0500"
Date: Thu, 27 Dec 2012 14:42:48 -0500
Message-ID: <17694.1356637368@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Nikolas Everett <nik9000@gmail.com> writes:
> After more digging it looks like this table has an inordinate number
> of indices (10 ish).

10 doesn't sound like a lot.

> There a whole buch of conditional indicies for other
> columns that we're not checking.  The particular column that is causing us
> trouble exists in both a regular (con_id) and a composite index (con_id,
> somthing_else).

You're not being at all clear here.  Are you trying to say that only
queries involving "WHERE col = constant" for a particular column seem
to be slow?  If so, maybe the column has a weird datatype or a wildly
out of line statistics target?  (Still hard to see how you get to 11-ish
seconds in planning, though.)

One thing you might do is watch the backend process in "top" or local
equivalent, and see if it's spending most of the 11 seconds sleeping, or
accumulating CPU time, or accumulating I/O.  That info would eliminate
a lot of possibilities.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance