Re: Slow Multi-joins performance [DEVELOPERS attn please]
От | jlparkinson@bigpond.com |
---|---|
Тема | Re: Slow Multi-joins performance [DEVELOPERS attn please] |
Дата | |
Msg-id | 02091607341500.02510@localhost обсуждение исходный текст |
Ответ на | Re: Slow Multi-joins performance [DEVELOPERS attn please] (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: