Johannes Verelst wrote: > Hi Reinder, > > > SELECT > >contentelementen.notitie,contentelementen.owner,contentelementen.number,contentelementen.vrijetekst6,contentelementen.datum2,contentelementen.datum1,contentelementen.vrijetekst5,contentelementen.vrijetekst4,contentelementen.vrijetekst3,contentelementen.vrijetekst2,contentelementen.vrijetekst1,contentelementen.elementtype,contentelementen.titel,contentelementen.body,contentelementen.toontitel,contentelementen.getal2,contentelementen.getal1,contentelementen.boolean2,contentelementen.boolean1,contentelementen.otype,contentelementen.intro,root0.number,insrel.number,contentelementen.number > >FROM cpb_contentelementen root0,cpb_insrel insrel,cpb_contentelementen > >contentelementen WHERE root0.number=888 AND ((root0.number=insrel.dnumber > >AND contentelementen.number=insrel.snumber AND > >insrel.dir<>1) OR (root0.number=insrel.snumber AND > >contentelementen.number=insrel.dnumber)) LIMIT 1 > > There might be reasons on postgres level that are causing that, but > note that these queries with an OR inside them are always heavy, on > all databases. These are generated by pieces of MMBase coe that don't > use a 'search direction'; so instead of just finding a parent or a > child, this will find all contentelements for which this element is > either the parent OR the child. > > Databases I know (MySQL and informix) don't like this. You far far > better of doing two seperate queries, or doing a union. For Informix > there is some database-support-code that exactly does this: generate a > union for two seperate queries. > > So, if possible, try to change your query (for instance use the > 'searchdir' parameter on the <mm:related> tags). That will most > definately help more than any database tuning.
Yes, and as we did last week, it is indeed possible to achieve to excact same result using 2 list-tags (with searchdir='source' and searchdir='destination), and using the 'add' and 'comparator' attribute on the second one :-) Of course that is a bit overly elaborate, and it may be a nice idea to change mmbase that in certain situations it would opt for such an explicit union automaticly. But for the moment indeed the best advice you can follow is to eliminate all these OR queries, which effectively means that if you follow relations between objects of the same type you _must always use the searchdir attribute_. For relations between object of different types, it cannot harm, but it will go automaticly well if you object-model is clean, and allows for the relation to be in one direction only. Michiel -- Michiel Meeuwissen mihxil' Peperbus 107 MediaPark H'sum []() +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
