Nikolas Everett <nik9000@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
