* Betr.: " Re: [tryton-dev] Performance and MPTT-Update" (Thu, 10 Mar 2011 15:23:36 +0100):
> On 10/03/11 15:17 +0100, Bertrand Chenal wrote: > > Le Thu, 10 Mar 2011 14:31:04 +0100, > > Cédric Krier <[email protected]> a écrit : > > > > > > > > > > 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? > > > > > > > Probably yes, > > (1) queries are expensive (each one add a round-trip to > > Posqtgresql), > > But the closures queries create much more records which cost also. > > > (2) when using closure table most of the work is made by > > Postgresql and save work in python (and C code is several magnitude > > quicker than python), > > I don't think it is the Python code of MPTT that is slow. The design by itself is slow. The scenario I built with only 2000 nested account views shows already the big performance problem of an ad hoc actualization of the tree. Just deleting one account from this simple tree takes 5-6 sec (depending of course from the hardware). Imagine a big warehouse with hundreds of shelves, thousands of sections... it just won't work. I am strongly adhering to the proposal to rebuild the tree on demand (i.e. the first search running on a dirty tree will rebuild it), thus saving a lot of unnecessary tree updates. Perhaps a way of rebuilding a dirty tree in the background in times of low load could be found? I am asking once again in this context for the inclusion of the patch I proposed, whether documented or undocumented (the responsibility of the developer could be pointed out, that he is in charge to take the correct measures and of rebuidling the tree). The patch is currently just a life-saver in everyday practical life. We had to interrupt account chart installations taking more than one day, because the postgres was lost in heavy transaction. With the patch the installation took 15-20m min. For us it is essential to have this switch, at least until there will be a more performant design. > > (3) it creates more data but they are not > > transferred. > > With MPTT neither. > > Also I'm not sure there is a simple way to rebuild the closure table if > corrupted with MPTT it is. If this design should be able to reduce the time needed for the ad hoc actualization in a *very* sensible way it should be taken into account. -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
