I am not perfectly sure what you mean by "transactional tables". Let me use the 
term "data handled in transaction" or "dhit" and try to forecast the issues.

AFAIK the "dhit" at the current OpenObject is in the form of python objects. 
They are stored in the server's memory, handled by its garbage collector and so 
on. Yes, there is many SQL commands issued inside each "rpc action", which are 
then committed at the end of the transaction. Still, Python has a reference of 
nearly all objects involved there. In some experiments I've been making, the 
counters often show as many as 5k SQL commands ! inside one transaction. In 
some case, 50k and 100k too! That is a problem, for sure.

As a quick remedy, the object model should be planned so that number of "dhit" 
objects is kept minimal (say, do you really need more than 100 lines in an 
invoice? , can you limit your search in products when you do the query? ).

Then, Postgres is a great tool in optimizing the data handling. Just like any 
decent database, it is destined to hold huge datasets and produce a reasonably 
fast result. The key there is that you don't foolishly ask for the whole 
dataset, but the right part of it. Given that you have the right indexes and no 
excess triggers, most db transactions perform fast and don't really depend on 
the rowcount of the table. My experience (since 2003) in Postgres has not yet 
found an upper limit to the data size.

Of course, we are *only* talking about using the latest Postgres in Linux (or 
Solaris, perhaps), using decent hardware and not compromize for anything less 
than those.

My humble conclusion is that now you should expect moderate performance with 
Object model, you may be lucky enough to store quite many rows before the model 
does something stu^H^H^Hsuboptimal and slows down. By the time you will have 
stored more data, all the components (OpenObject, db, Linux, hardware) will 
have progressed so that you will enjoy the desired scalability.




-------------------- m2f --------------------

--
http://www.openerp.com/forum/viewtopic.php?p=29184#29184

-------------------- m2f --------------------


_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users

Reply via email to