| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | "mascarm(at)mascari(dot)com" <mascarm(at)mascari(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Any optimizations to the join code in 7.1? |
| Date: | 2001-04-28 01:49:09 |
| Message-ID: | 3AEA2195.2415244A@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> ... 7.1 out of the box took only 2 seconds! I was amazed
> and shocked at this damned impressive improvement in planning
> speed....until I actually used the explicit JOIN syntax described in
> 11.2. Instanteous results! Instantaneous.....
But it is possible, under many circumstances, for query optimization to
be a benefit for a many-table query. The docs indicate that explicit
join syntax bypasses that, even for inner joins, so you may find that
this syntax is a net loss in performance depending on the query and your
choice of table order.
Presumably we will be interested in making these two forms of inner join
equivalent in behavior in a future release. Tom, what are the
impediments we might encounter in doing this?
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | balloon | 2001-04-28 01:53:14 | after changing login password (local), CPU always 100% !! |
| Previous Message | Bruce Momjian | 2001-04-28 01:45:24 | Re: Re: The new, the improved ... FTS Searching of Mailing List Archives |