DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=Q6hM6MvfbkI8ryC2FwbER3jxMu8UfZfn+zrV4J/enegTWMiMZGNuepsHU/ly2S8mWsJ8p2+hDTxOUxKGLXmLYBP0Z3+XHvSpLZpFFSGkahJPyznuJx2uzTSWlXHren67Dyz3JqjiV4Hgp3Jd1GVpekgKrJ+QcVC1GhqmLUHIE8w=
Message-ID: <eb4939fe0703130636r664d32e9qd8d3975635c7786c@mail.gmail.com>
Date: Tue, 13 Mar 2007 14:36:47 +0100
From: "James Riordan" <james.riordan@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Dispatch-Merge pattern
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Howdy-

I am currently using PostgreSQL to store and process a high-bandwidth
event stream.  I do not need old events but the delete and vacuum does
not terminate due to the large number of events being inserted (it
just pushes me over the tipping point of where the machine can keep up
with the events).

I ended up implementing a scheme where a trigger is used to redirect
the events (round robin based on time) to a series of identically
structured tables.  I can then use TRUNCATE older tables rather than
DELETE and VACUUM (which is a significant speed up).

It worked out pretty well so thought post the idea to find out if

 - it is stupid way of doing things and there is a correct database
   abstraction for doing this

or

  - it is a reasonable way of solving this problem and might be of use
    to other folks using rdbs as event processing

I then use a view to merge the tables.  Obviously update would be a
problem for my purposes, and I suppose a lot of event processing, it
isn't an issue.

Either way, details are at:
  http://unsyntax.net/james/blog/tools+and+programming/2007/03/08/Dispatch-Merge-Database-Pattern

Cheers,
James