Content-Type: text/plain;
  charset="iso-8859-1"
From: jlparkinson@bigpond.com <jlparkinson@bigpond.com>
Reply-To: jlparkinson@bigpond.com
To: pgsql-sql@postgresql.org
Subject: Re: Slow Multi-joins performance [DEVELOPERS attn please]
Date: Mon, 16 Sep 2002 07:34:15 +1000
References: <02090620595601.02695@localhost>
	<200209091624.08766.dev@archonet.com>
	<13474.1031603202@sss.pgh.pa.us>
In-Reply-To: <13474.1031603202@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <02091607341500.02510@localhost>
Content-Transfer-Encoding: 8bit

On Tue, 10 Sep 2002 06:26, Tom Lane wrote:
> Richard Huxton <dev@archonet.com> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Does this mean that v7.3 will be about three (3) times faster than v7.1 so 
that it matches MySQL and MS-ACCESS?

Or is Postgresql slow for multi-joins with small amounts of data, and only 
come into its own when there is more than a million records involved 
(suggested in a previous reply, that using caching of query plans will 
increase speed)?

regards,
James