Message-ID: <4C2B798E.70606@emolecules.com>
Date: Wed, 30 Jun 2010 10:06:22 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
	rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL as a local in-memory cache
References: <cb0fb58c-9134-4314-a1d0-08fc39f911a6@40g2000pry.googlegroups.com>
	<AANLkTilmwmDBLCBiqLWh7OfMqGae9ocJScAdDoq1-LEY@mail.gmail.com>
In-Reply-To: <AANLkTilmwmDBLCBiqLWh7OfMqGae9ocJScAdDoq1-LEY@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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