Skip site navigation (1) Skip section navigation (2)

Re: Possibilities of PgSQL

From: Shane Ambler <pgsql(at)Sheeky(dot)Biz>
To: Karel Břinda <konference(at)brinda(dot)info>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Possibilities of PgSQL
Date: 2007-08-23 12:51:51
Message-ID: 46CD82E7.8070605@Sheeky.Biz (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Karel Břinda wrote:
> Hi,
> I have a question about PgSQL. I am working at some project and I want
> to have few tables with special properties:
> There would be many rows and these would be changed every day for many
> times. I want to be able to get know how did the row looked in given
> time (f.e. 2 day ago, 6 minutes ago, 2nd Sept. 2002,...). Nevertheless
> it should work with diffs (f.e. if I had a row with 100MB string and I
> changed only 2 chars it should not require on disk 200MB but only 100MB
> + few (kilo)Bytes).

100MB of text in each row?? is each row a copy of the english dictionary?

My thoughts are to have a table that records the changes, something 
along the lines of a timestamp of the change with substring start and 
end positions of the change with the before and after text that has 
changed that can be used to 'replay' the changes.

When you want to rewind to a certain time you find all entries after the 
given time and undo the changes to get back to where it was.

> Is there any possibility how to solve it? I have heard that I can do it
> with triggers (but the worst thing is how to implement diffs) but I hope
> that there is any other (easier) way.

Triggers are the most reliable way to implement this, I would think that 
pl/perl may be the fastest way to implement it as a trigger.

Basically you would need to compare before and after as the record was 
saved - doing that with 100MB of data will make saving changes somewhat 

What sort of client is updating this data?
I would think that the client could keep track of changes as they are 
typed and save this info with the updated data thus removing the time to 
compare the before and after data at the DB end.


Shane Ambler

Get Sheeky @ http://Sheeky.Biz

In response to


pgsql-admin by date

Next:From: Kevin GrittnerDate: 2007-08-23 13:43:54
Subject: Re: "Stand-in" server recovery techniques
Previous:From: Tena SakaiDate: 2007-08-23 06:05:11
Subject: Re: tar, but not gnu tar

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group