Re: BUG #13592: Optimizer throws out join constraint causing incorrect result

Tom, David,
You are correct. I'm sorry, gotten accustomed to the join criteria/table relationship taking first seat over other expression.

Just to fill in,
> For example, if both A and C are small and both could usefully be used in an indexscan on a large B table, joining A to C first would make perfect sense.

A is much larger than B and C; B contains the least number of entries (~6 in this DB); C slightly larger than B (~60). Report indicated B required Vacuum/Analyze so I guess optimizer saw more than those ~6.

Guess fix will be either similar to example or force the B/C relation to evaluate first into D.

Also, I apologize for the blob message included at end of mail, it is attached by server on outgoing mail.

Regards
Kristoffer Gustafsson

________________________________

Detta meddelande och alla bilagor är konfidentiella och avsedda för den namngivna mottagaren. Om du har fått detta meddelande av misstag, vänligen meddela omedelbart avsändaren och ta sedan bort meddelandet. All otillåten modifiering, användning eller spridning är förbjuden. Avsändaren är inte ansvarig för detta meddelande om det har ändrats, förfalskats, redigerats, smittat av ett virus eller spridits utan tillstånd. Skriv inte ut detta meddelande om det inte är nödvändigt, tänk på miljön.

This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender is not liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. Do not print this message unless it is necessary, consider the environment.