Re: [HACKERS] Time travel

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: chris(at)bitmead(dot)com
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Time travel
Date: 2000-02-04 22:15:11
Message-ID: 389B4F6F.89B0221A@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Bitmead wrote:
>
> Now in the documentation it mentioned removing time travel because
> "performance impact, storage size, and a pg_time file which
> grows toward infinite size in a short period of time.".

In the time this was written 200MB disk was a big disk.

> Now since I believe the postgres storage manager does not replace
> records in place when updated,

Yes, it's true at least for 6.5.3 (I've written a small script that
extracts the old/hidden tuples) and I'm pretty sure that for 7.x too
perhaps it is the removal of pg_time (which i think recorded correspondence
between transaction ids and timestamps) that gives the big performance win.

> I can't see how it is different to
> having the time travel feature with vacuum configured to remove
> all old records immediately. I don't know what the pg_time file
> is.

I guss it could be just a add_only, monotonuously growing 'tape'-type file,
suitable for being searched using binary search. So really not nearly as
much overhead as would be a regular pg table with two indexes.

> Have I missed something about why taking out time travel has
> improved performance, as opposed to simply making immediate
> vacuum the default? Clearly the performance of triggers as an
> alternative is going to suck very badly, since the postgres
> storage manager was built specially from the ground up to
> support time travel with its non-update semantics, and it
> still has these characteristics.

Implementing time-travel with triggers wil actually give us double
time-travel, on hidden and one visible ;)

In response to

  • Time travel at 2000-02-04 05:16:43 from Chris Bitmead

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-02-04 22:37:35 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous Message Assaf Arkin 2000-02-04 21:48:38 Identifying duplicate key inserts