Re: PostgreSQL as a local in-memory cache

From: Craig James <craig_james(at)emolecules(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL as a local in-memory cache
Date: 2010-06-30 17:06:22
Message-ID: 4C2B798E.70606@emolecules.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 6/30/10 9:42 AM, Dave Crooke wrote:
> I haven't jumped in yet on this thread, but here goes ....
>
> If you're really looking for query performance, then any database which
> is designed with reliability and ACID consistency in mind is going to
> inherently have some mis-fit features.
>
> Some other ideas to consider, depending on your query mix:
>
> 1. MySQL with the MyISAM database (non-ACID)
>
> 2. Put an in-application generic query cache in front of the DB, that
> runs in the app address space, e.g. Cache' if using Java
>
> 3. Using a DB is a good way to get generic querying capability, but if
> the "where" clause in the querying is over a small set of meta-data, and
> SQL syntax is not a big requirement, consider non-RDBMS alternatives,
> e.g. use XPath over a W3C DOM object tree to get primary keys to
> in-memory hash tables (possibly distributed with something like memcached)

These would be good suggestions if the "throwaway" database was the only one. But in real life, these throwaway databases are built from other databases that are NOT throwaway, where the data matters and ACID is critical. In other words, they'll probably need Postgres anyway.

Sure, you could use both Postgres and MySQL/ISAM, but that means installing and maintaining both, plus building all of the other application layers to work on both systems.

Craig

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message tony 2010-06-30 18:12:27 Re: Architecting a database
Previous Message Dave Crooke 2010-06-30 16:42:50 Re: PostgreSQL as a local in-memory cache