Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 2AE43476033 for ; Mon, 9 Sep 2002 16:26:59 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 8DB3B475EBF for ; Mon, 9 Sep 2002 16:26:58 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g89KQgKo013475; Mon, 9 Sep 2002 16:26:42 -0400 (EDT) To: Richard Huxton Cc: jlparkinson@bigpond.com, pgsql-sql@postgresql.org Subject: Re: Slow Multi-joins performance [DEVELOPERS attn please] In-reply-to: <200209091624.08766.dev@archonet.com> References: <02090620595601.02695@localhost> <200209091624.08766.dev@archonet.com> Comments: In-reply-to Richard Huxton message dated "Mon, 09 Sep 2002 16:24:08 +0100" Date: Mon, 09 Sep 2002 16:26:42 -0400 Message-ID: <13474.1031603202@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/59 X-Sequence-Number: 9336 Richard Huxton writes: > Which says to me that your form is fine. Testing says otherwise, so there must > be some element of the query that is not being accounted for in EXPLAIN > ANALYSE. To wit, planning time. EXPLAIN ANALYZE only counts execution time. And planning time on a 13-way join is going to be nontrivial --- especially compared to execution against trivial-size tables. You can turn on some query stats logging (I forget the SET-variable names) to get a feeling for the relative costs of planning and execution; but usually planning drops into the noise once you start looking at production-sized cases. regards, tom lane