Michael Monnerie <lists.michael.monnerie@xxxxxxxxxxxxxxxxxxx> writes: > Am 26.04.2014 20:27, schrieb Tom Lane: >> Could the planning time possibly account for that? How long does a >> plain EXPLAIN of the same query take? regards, tom lane > But I see lots of log entries with this query, all around 1200ms. That's > why I started investigating: Hmm ... that leads to a different idea: maybe you have got some other operation that is (repeatedly) holding an exclusive lock on one of these tables for about 1200ms? The time needed to acquire AccessShareLock on a table being selected from is spent in the parser, so that wouldn't be accounted for either by EXPLAIN's total runtime. That theory isn't totally satisfying because you wouldn't expect unrelated processes to all suffer the same wait time, but it's worth eliminating lock waits as a factor in this. Try turning on log_lock_waits with a threshold of a few hundred ms. > Here's the EXPLAIN w/o ANALYZE (exactly the same): This output doesn't answer my question, which is how long did the EXPLAIN command take? You could run it with psql's \timing turned on. > PS: Is there anything I could possibly optimize in that query by another > index? I don't see anything obvious. Optimization isn't the problem here: whatever is delaying these queries is happening outside execution proper. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
