"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
>>> 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:
>> 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 i
>>> 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 i
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 th
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?
>
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
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 w
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. Yo
"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 prett
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 an
11 matches
Mail list logo
