Hi,
> 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. >> > In my case, the join_collapse property was flexible when I needed it. Disable the optimizer, means set the join_collapse as the number of relations in the query or use a 'higher' number. > 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. > Yes, it applies to whole query in Postgres. I agree, the fined grained control would be better, maybe the hint could be extended to use an specific index too, among another things. However, I think the join_collapse would be more simple to implement. > 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? > I really don't know. ;-) Regards, Fred -- 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.
