On 10/03/11 12:50 +0100, Bertrand Chenal wrote: > Le Thu, 10 Mar 2011 12:36:31 +0100, > Cédric Krier <[email protected]> a écrit : > > > On 10/03/11 12:26 +0100, Bertrand Chenal wrote: > > > Le Wed, 9 Mar 2011 15:58:17 +0100, > > > Cédric Krier <[email protected]> a écrit : > > > > > > > > > > > Furthermore we should evaluate the possibilities to delay the > > > > > MPTT update till the end of any encapsulating transaction. The > > > > > idea is to run the MPTT update only at the end of the first of > > > > > perhaps multiple nested transaction. > > > > > > > > > > Comments and thoughts welcome. > > > > > > > > I don't find that delaying or postpone the update of MPTT is a > > > > good idea. Because the system is build on the assumption that it > > > > can use MPTT for search at any time, so inside the same > > > > transaction you could use it just after modification of the tree. > > > > > > What about delaying it only until the next search (I.E, write/create > > > mark the tree as dirty, search trigger mptt computation if the tree > > > is dirty) ? Like that the assumption is still valid, but massive > > > insert is not affected. > > > > I don't like too much that a search modify the tree. > > And more over, search rpc calls are done in a non-commited > > transaction. > > > > Another solution is to drop mptt and use a closure table[1], it seems > to generate far less queries to maintain the index.
Less query but more rows so is it really faster? -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpflRFiDwQdm.pgp
Description: PGP signature
