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
