> > > It may be that WAL has changed the rollback
> > > time-characteristics to worse than pre-wal ?
> >
> > Nothing changed ... yet. And in future rollbacks
> > of read-only transactions will be as fast as now,
> > anyway.
> 
> What about rollbacks of a bunch uf inserts/updates/deletes?
>
> I remember a scenario where an empty table was used
> by several backends for gathering report data, and
> when the report is done they will rollback to keep
> the table empty.
>
> Should this kind of usage be replaced in the future by 
> having backend id as a key and then doing delete by that 
> key in the end ?

Isn't it what we have right now?
But I believe that in future we must remove
modifications made by aborted transactions
immediately, without keeping them till vacuum.
So - yes: rollback of read-write transactions
will take longer time.

Vadim

-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com



Fri, 23 Feb 2001 09:41:57 -0500 (EST)
Vadim Mikheev <vadim4o@email.com>
Re: RE: Re: [ADMIN] v7.1b4 bad performance
Vadim Mikheev wrote:

>> Should this kind of usage be replaced in the future by 
>> having backend id as a key and then doing delete by that 
>> key in the end ?
> 
> 
> Isn't it what we have right now?

I meant doing it at the application level, not what backend does internally.

Like we are supposed to implement time-travel now that it is (mostly) 
gone from core functionality :c)

> But I believe that in future we must remove
> modifications made by aborted transactions
> immediately, without keeping them till vacuum.
> So - yes: rollback of read-write transactions
> will take longer time.

but will

INSERT-DELETE-COMMIT
take longer than

INSERT-ABORT

?

----------------
Hannu


Fri, 23 Feb 2001 17:00:21 +0200
Hannu Krosing <hannu@tm.ee>
Re: RE: Re: [ADMIN] v7.1b4 bad performance