Re: Temporal Databases

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Rodrigo Sakai <rodrigo(dot)sakai(at)poli(dot)usp(dot)br>, Michael Glaesemann <grzm(at)myrealbox(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Temporal Databases
Date: 2006-02-25 23:46:10
Message-ID: 20060225234610.GQ82012@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Feb 24, 2006 at 11:56:58AM -0500, Brad Nicholson wrote:
> Simon Riggs wrote:
>
> >A much easier way is to start a serialized transaction every 10 minutes
> >and leave the transaction idle-in-transaction. If you decide you really
> >need to you can start requesting data through that transaction, since it
> >can "see back in time" and you already know what the snapshot time is
> >(if you record it). As time moves on you abort and start new
> >transactions... but be careful that this can effect performance in other
> >ways.
>
> We're currently prototyping a system (still very much in it's infancy)
> that uses the Slony-I shipping mechanism to build an off line temporal
> system for point in time reporting purposes. The idea being that the
> log shipping files will contain only the committed inserts, updates and
> deletes. Those log files are then applied to an off line system which
> has a trigger defined on each table that re-write the statements, based
> on the type of statement, into a temporally sensitive format.
>
> If you want to get an exact point in time snapshot with this approach,
> you are going to have to have timestamps on all table in your source
> database that contain the exact time of the statement table. Otherwise,
> a best guess (based on the time the slony sync was generated) is the
> closest that you will be able to come.

Have you looked at using timelines in PITR for stuff like this?
Depending on your needs, it might be less work to do it this way.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message sfourman 2006-02-25 23:57:18 Postgres Win32 libpq Samples
Previous Message Jim C. Nasby 2006-02-25 23:14:23 Re: ltree + gist index performance degrades significantly over a night