AW: Plans for solving the VACUUM problem

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: Plans for solving the VACUUM problem
Date: 2001-05-21 14:44:42
Message-ID: 11C1E6749A55D411A9670001FA6879633682DA@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > Vadim, can you remind me what UNDO is used for?
> 4. Split pg_log into small files with ability to remove old ones (which
> do not hold statuses for any running transactions).

They are already small (16Mb). Or do you mean even smaller ?
This imposes one huge risk, that is already a pain in other db's. You need
all logs of one transaction online. For a GigaByte transaction like a bulk
insert this can be very inconvenient.
Imho there should be some limit where you can choose whether you want
to continue without the feature (no savepoint) or are automatically aborted.

In any case, imho some thought should be put into this :-)

Another case where this is a problem is a client that starts a tx, does one little
insert or update on his private table, and then sits and waits for a day.

Both cases currently impose no problem whatsoever.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2001-05-21 14:53:13 Re: RE: Plans for solving the VACUUM problem
Previous Message Tom Lane 2001-05-21 14:06:35 Re: Plans for solving the VACUUM problem