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
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 |