| From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
|---|---|
| To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
| Cc: | "'bpalmer'" <bpalmer(at)crimelabs(dot)net>, Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why vacuum? |
| Date: | 2000-12-14 15:57:32 |
| Message-ID: | 20001214095732.A10552@rice.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
>
> 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.
>
Not to mention the recent thread here about people recovering data that
was accidently deleted, or from damaged db files: the old tuples serve
as redundant backup, in a way. Not a real compelling reason to keep a
non-overwriting smgr, but still a surprise bonus for those who need it.
Ross
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross J. Reedstrom | 2000-12-14 16:14:13 | Re: Why vacuum? |
| Previous Message | Michael Richards | 2000-12-14 15:55:32 | Re: (Updated) Table File Format |