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

Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly

From: Guy Fraser <guy(at)incentre(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly
Date: 2004-04-26 19:58:57
Message-ID: 408D6A01.3050908@incentre.net (view raw or flat)
Thread:
Lists: pgsql-general
Alvaro Herrera wrote:

>On Mon, Apr 26, 2004 at 12:53:09PM -0600, Guy Fraser wrote:
>
>  
>
>>Eventually the automatic purging of  'stale' data will be supported,
>>but hopefully it will be configurable to allow 'time travel' when
>>required, and allow for a reasonable time to be able to roll back
>>transactions.
>>    
>>
>
>Well, you are saying two different things here: to garbage-collect
>automatically the database (rather than by manual VACUUMs), and to be
>able to UNDO transactions, effectively going back in time.
>
>The former is likely to be supported in some not-too-distant future,
>maybe hopefully the next release; the latter is not even planned, and in
>the past it has been disregarded as too costly.  Not implementation
>time cost, mind you, but runtime cost.
>  
>
I realize that one you vacuum you can no longer time travel to before the vacuum. Although I never tried to use it, I thought time travel was a feature in PostGreSQL. My understanding of the time travel feature was to allow a query to be processed with the data set as it was at a previous time. Since I did not have need for that feature fro any of the  
projects I have been involved in, I did not check to see how it worked, or followed it's development or demise as it may be.

Thank you for the update, I will not use time travel in further explanations of transactional integrity.:-)




In response to

Responses

pgsql-general by date

Next:From: Glen ParkerDate: 2004-04-26 20:25:59
Subject: Re: shadowing (like IB/Firebird)
Previous:From: Dann CorbitDate: 2004-04-26 19:48:45
Subject: Re: Arbitrary precision modulo operation

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