"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> SELECT *
>> FROM a LEFT JOIN
>> (SELECT * FROM b JOIN c ON b.y = c.z WHERE b.y = 10) ss
>> ON a.x = ss.y
>> WHERE a.x = 42;
>>
>> ... In this example, notice also that
>> a.x = ss.y (really a.x = b.y) is not an equivale
Tom Lane writes:
> Attached is some material from an updated src/backend/optimizer/README
> that describes the optimization principles that the EquivalenceClass
> rewrite is depending on. Can anyone see any holes in the logic?
Sounds good, I can see no holes.
> SELECT *
> FROM a LE
Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
pathkeys since we can say nothing about the overall order of its result.
Yeah, but it might come back someday, so I didn't feel a need to change
that sentence...
Hmm. Our OR patch makes the same possibility by using Append
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
>> pathkeys since we can say nothing about the overall order of its result.
> It's seems to me that multi-pass indexscan was removed after introducing
> bitmapscan.
Yeah, but it
Note that a bitmap scan or multi-pass indexscan (OR clause scan) has NIL
pathkeys since we can say nothing about the overall order of its result.
It's seems to me that multi-pass indexscan was removed after introducing
bitmapscan.
--
Teodor Sigaev E-mail: [EMAI
On Thu, 2007-01-18 at 11:53 +1100, Gavin Sherry wrote:
> the major rule in the executor: do what ever the plan tells you to do.
I thought the rule was: do what the plan tells you to do, as efficiently
as possible.
Turning an explicit step into a no-op seems like great execution to me.
In the cas
On Wed, 17 Jan 2007, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I was thinking about this, but in relation to hash joins. A hash join
> > cannot be guaranteed to produce output sorted according to the pathkey of
> > the outer relation (as explained in the existing README). I wo
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I was thinking about this, but in relation to hash joins. A hash join
> cannot be guaranteed to produce output sorted according to the pathkey of
> the outer relation (as explained in the existing README). I wonder,
> however, if it might be useful for has
On Wed, 17 Jan 2007, Tom Lane wrote:
> strict. However, we also allow equivalence clauses that appear below the
> nullable side of an outer join to form EquivalenceClasses; for these
> classes, the interpretation is that either all the values are equal, or
> all (except pseudo-constants) have gon
Attached is some material from an updated src/backend/optimizer/README
that describes the optimization principles that the EquivalenceClass
rewrite is depending on. Can anyone see any holes in the logic?
I'm particularly interested in the discussion of allowing
EquivalenceClasses to be deduced fr
10 matches
Mail list logo
