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. Johannes -- Mail: mailto:[EMAIL PROTECTED] Web: http://www.verelst.net Blog: http://keukenhelden.nl/johannes _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
