| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | lockhart(at)fourpalms(dot)org |
| Cc: | "mascarm(at)mascari(dot)com" <mascarm(at)mascari(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: Any optimizations to the join code in 7.1? |
| Date: | 2001-04-30 15:22:16 |
| Message-ID: | 15130.988644136@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> 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?
I don't think there are any real technical problems in the way; it's
simply an implementation choice not to treat INNER JOIN the same as an
implicit join list. I did it that way in 7.1 mainly as a flyer, to see
how many people would think it's a feature vs. how many think it's a
bug. The votes aren't all in yet, but here we have Mike apparently
pretty pleased with it, while I recall at least one other person who
was not happy with the 7.1 behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-04-30 15:36:58 | Re: COPY commands could use an enhancement. |
| Previous Message | Thomas Lockhart | 2001-04-30 15:02:08 | Re: v7.1.1 branched and released on Tuesday ... |