> 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.
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.
> 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? ;-)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
