Thanks Iceberg - this makes some sense... On Mon, Apr 13, 2009 at 11:28 PM, Iceberg <[email protected]> wrote:
> > Thanks Yarko's insight on the topic of db performance domain. > > As to me, I brought up the issue only because I want to store sessions > in RAM. In many cases sessions are not needed to be persistent on > disk. Ram means maintenance free here, that way there is no need to > delete old session files anymore. By the way, I personally plan to > develop an desktop app which will be run on a CD, so the disk is not > writable at all. Mmm, still a long way to reach that goal, but ram- > based session will be the first milestone. > > So, if only sessions can be put in ram, that is ok for me. If an > entire db can be fit into ram, that is better because session can be > stored in this ram db by session.connect(...,db). > > On Apr14, 2:17am, Yarko Tymciurak <[email protected]> wrote: > > temporary tables as a performance issue seem reasonable... > > Solving database storage performance in web2py seems the _wrong_ place to > do > > this. > > > > Temporary tables (per-request) which help manage web2py's assumption that > > everything is data-driven, that is so you can take advantage of forms, > etc. > > seems like a good use of ram-based / "virtual" tables for per-request > > situations where you want to have the full web2py API at your disposal > > (validations, forms, etc). > > > > Temporary (ram-based) tables to address persistent data performance > issues > > should NOT be solved by web2py (if you find some _really compelling_ > reason > > that there is some exceptional case where this makes sense, by all means > > present your case! but I don't see anything approaching that right > now...) > > > > Data-presistence performance issues (that is, back end issues) should be > the > > domain of, and solved by the backend. Some suggestions: Re-structure > what > > you are doing to avoid your specific situation (why are you creating > _many_ > > temporary tables???); select a deb backend that supports temporary > tables > > or other performance concerns that are specific to those you are > > experiencing (Oracle and T-SQL, Postgres at least support temporary > tables). > > > > IN this regard, it _might_ make sense to have DAL support a "as > TEMPORARY" > > option for table definiton (as a hint - if the backend supports it, it > will > > use it, otherwise you just get a "normal" table). I have no idea what > the > > various options and behaviors of temporary tables are, but this (at > least) > > would be in the right direction for web2py.... > > > > I'm really not (at this point) for this particular proposal - I would > much > > prefer to see thinking around something more like: > > > > db.table_create('sometable', ......, migrate=Temporary) # ? or maybe a > > separate keyword, but this _does_ seem like a kind of migration issue > > > > More discussion please! > > > > - Yarko > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
