From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'bpalmer'" <bpalmer(at)crimelabs(dot)net>, Alfred Perlstein <bright(at)wintelcom(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: Why vacuum? |
Date: | 2000-12-14 11:07:00 |
Message-ID: | 11C1E6749A55D411A9670001FA68796336817E@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Yes, postgresql requires vacuum quite often otherwise queries and
> > updates start taking ungodly amounts of time to complete. If you're
> > having problems because vacuum locks up your tables for too long
> > you might want to check out:
>
> But why? I don't know of other databases that need to be
> 'vacuum'ed. Do
> all others just do it internaly on a regular basis?
>
> What am I missing here?
They all have an overwriting storage manager. The current storage manager
of PostgreSQL is non overwriting, which has other advantages.
There seem to be 2 answers to the problem:
1. change to an overwrite storage manager
2. make vacuum concurrent capable
The tendency here seems to be towards an improved smgr.
But, it is currently extremely cheap to calculate where a new row
needs to be located physically. This task is *a lot* more expensive
in an overwrite smgr. It needs to maintain a list of pages with free slots,
which has all sorts of concurrency and persistence problems.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Perchine | 2000-12-14 11:57:32 | Re: Why vacuum? |
Previous Message | Philip Hofstetter | 2000-12-14 10:42:11 | Thanks! |