On Jul 5, 2007, at 13:20 , Andrew Sullivan wrote:
On Sun, Jul 01, 2007 at 11:11:30PM +0200, Alexander Todorov wrote:
The question was is there something else that exists in PostgreSQL
and
will do the same job.
Why re-invent the wheel, and make it square? But also, if you don't
care whether you keep your data, why on earth are you putting it in
an RDBMS? Is it because all your pre-built tools already speak SQL?
If you're really after performance, I'm not convinced a SQL-speaking
RDBMS (delivered by MySQL or Postgres or anyone else) is what you
actually need.
Look- there are plenty of scenarios where data one does not care
about is linked (in a relational fashion) to data one does care
about. One common example is a web session. If your database fails,
then the sessions are really irrelevant in the future. Another
example is a live queue or snapshot of other data (materialized views?).
As long as the database is running, then the data is useful. Such a
table can contain foreign keys but no triggers and may not have
references to it from "non-temp" tables.
Why not have a table type that writes no WAL and is truncated
whenever postgres starts? Such a table could then be put in a ramdisk
tablespace and there would be no transaction atomicity repercussions.
Is there something I'm missing?
Claiming that postgresql is simply the wrong tool is silly,
especially since it is so close to having the desired behavior.
Cheers,
M
