2010/6/24 Josh Berkus <josh@xxxxxxxxxxxx>: > >> this is similar MySQL's memory tables. Personally, I don't see any >> practical sense do same work on PostgreSQL now, when memcached exists. > > Thing is, if you only have one table (say, a sessions table) which you > don't want logged, you don't necessarily want to fire up a 2nd software > application just for that. Plus, recent testing seems to show that with > no logging, memcached isn't really faster than PG. sorry, I thinking some else. Not only WAL does significant overhead. You need litlle bit more memory, much more processing time. With very fast operations, the bottle neck will be in interprocess communication - but it doesn't mean so pg isn't slower than memcached. I repeating it again - there are no any universal tool for all tasks. > > Also, like for asynch_commit, this is something where users are > currently turning off fsync. Any option where we can present users with > controlled, predictable data loss instead of random corruption is a good > one. > it isn't too simple. What about statistics? These are used in system table. >> Much more important is smarter cache controlling then we have now - >> maybe with priorities for some tables and some operations >> (applications) - sometimes we don't need use cache for extra large >> scans. > > Well, that would be good *too*. You working on it? ;-) > no - just I know about possible problems with memory control. > -- > -- Josh Berkus > PostgreSQL Experts Inc. > http://www.pgexperts.com > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
