From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nikolas Everett <nik9000(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: explain analyze reports that my queries are fast but they run very slowly |
Date: | 2012-12-27 19:42:48 |
Message-ID: | 17694.1356637368@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Nikolas Everett <nik9000(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2012-12-27 19:57:09 | sched_migration_cost for high-connection counts |
Previous Message | Nikolas Everett | 2012-12-27 19:29:29 | Re: explain analyze reports that my queries are fast but they run very slowly |