> > Sorry, I missed this e-mail before I send mine. My initial idea about > join_collapse_limit was already proposed. I didn't understand the SQL > Server syntaxe, how force the ordering for an internal Select node? I > agree, the postgres way is less flexible, but this saved me in some of > situations. I'm not sure, but the postgres way would be more easily to > implement (right?). >
The easiest thing is to disable the optimiser completely for a given select. The optimiser reorders the joins. A hint, in essense a single flag would tell it not to. I may be wrong but the join collapse system is both more flexible in certain ways and less flexible in others. It allows some control over the joining, so some optimisation can take place, whilst other parts are fixed, but applies to the whole query and not sub queries (unless I have misunderstood). I would have said fine grained control would be better done by annoting the individual joins. I am not sure what the thinking is behind the join collapse system, it seems arbitrary. Perhaps it is historical and relates to issues with early postgres versions? - mike -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
