Re: Slow Multi-joins performance [DEVELOPERS attn please]

From: jlparkinson(at)bigpond(dot)com <jlparkinson(at)bigpond(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: Slow Multi-joins performance [DEVELOPERS attn please]
Date: 2002-09-15 21:34:15
Message-ID: 02091607341500.02510@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Tue, 10 Sep 2002 06:26, Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)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

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2002-09-16 04:03:32 Re: Table alias in DELETE statements
Previous Message Tom Lane 2002-09-15 14:51:42 Re: Timestamp Fractions Problem