| From: | Vadim Mikheev <vadim4o(at)email(dot)com> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Schmidt, Peter" <peter(dot)schmidt(at)prismedia(dot)com> |
| Subject: | Re: RE: Re: [ADMIN] v7.1b4 bad performance |
| Date: | 2001-02-23 14:41:57 |
| Message-ID: | 387428168.982939317658.JavaMail.root@web444-ec.mail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2001-02-23 15:00:21 | Re: RE: Re: [ADMIN] v7.1b4 bad performance |
| Previous Message | Dave Mertens | 2001-02-23 12:21:32 | Re: [HACKERS] Re: v7.1b4 bad performance |