Tom Lane [EMAIL PROTECTED] wrote:
Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing
JOIN_IN. Unify the InClauseInfo and OuterJoinInfo infrastructure
into
SpecialJoinInfo. Convert IN, EXISTS, and NOT EXISTS clauses at
top
level of WHERE into semi and anti joins
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing
JOIN_IN.
It just struck me that this may cause additional joins to count
against the join_collapse_limit. If so, that could cause some
borderline
On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
We're just trying to provide better performance for certain common SQL
idioms.
Sounds good, but can you explain how this will help? Not questioning it,
just after more information about it.
I'm half way through join removal patch, so this
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
We're just trying to provide better performance for certain common SQL
idioms.
Sounds good, but can you explain how this will help?
1. Allowing optimization of EXISTS/NOT EXISTS as general-purpose joins.
On Thu, 2008-08-14 at 10:04 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2008-08-13 at 23:12 -0400, Tom Lane wrote:
We're just trying to provide better performance for certain common SQL
idioms.
Sounds good, but can you explain how this will help?
1. Allowing
Simon Riggs [EMAIL PROTECTED] writes:
OK, that sounds good. Are you also working on transforming NOT IN into
different form? Or is that the same thing as (1)?
I'm not currently thinking about NOT IN. It could be transformed to
an antijoin if we could prove that no nulls are involved, but that
Tom Lane [EMAIL PROTECTED] wrote:
I can't yet *prove* that I can get better estimates
with the added info, but if not, that just means I need to rethink
what
to pass down exactly.
I'll see if I can do some testing here to confirm plan improvements
and check estimate accuracy. This is only
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I can't yet *prove* that I can get better estimates
with the added info, but if not, that just means I need to rethink what
to pass down exactly.
I'll see if I can do some testing here to confirm plan improvements
On Aug 13, 2008, at 17:31, Tom Lane wrote:
What's done:
Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing
JOIN_IN. Unify the InClauseInfo and OuterJoinInfo infrastructure into
SpecialJoinInfo. Convert IN, EXISTS, and NOT EXISTS clauses at top
level of WHERE into semi and
David E. Wheeler [EMAIL PROTECTED] writes:
On Aug 13, 2008, at 17:31, Tom Lane wrote:
Introduce JOIN_SEMI and JOIN_ANTI join types,
Wow. That sound awesome, Tom. Stupid question: Do these join types
have some sort of correspondence to the SQL standard?
Semi and anti joins are pretty
On Aug 13, 2008, at 20:12, Tom Lane wrote:
Wow. That sound awesome, Tom. Stupid question: Do these join types
have some sort of correspondence to the SQL standard?
Semi and anti joins are pretty standard concepts in relational theory,
but they have no direct mapping in the SQL join syntax.
11 matches
Mail list logo
