| From: | Daniele Orlandi <daniele(at)orlandi(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why vacuum? |
| Date: | 2000-12-14 17:24:26 |
| Message-ID: | 3A39024A.DF9E3AD8@orlandi.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Ross J. Reedstrom" wrote:
>
> On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
> >
> > 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.
I don't agree. If (as I have proposed) the search is made in the
background by a low priority process, you just have to lookup a cache
entry to find out where to write.
> > It needs to maintain a list of pages with free slots,
> > which has all sorts of concurrency and persistence problems.
Concurrency is a problem, but a spinlock on a shared-memory table should
suffice in the majority of the cases[1]. I may be wrong... but I think
it should be discussed.
[1] I believe that already there's a similar problem to synchronize the
backends when the want to append a new page.
Bye!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alfred Perlstein | 2000-12-14 17:38:55 | Re: Why vacuum? |
| Previous Message | Alfred Perlstein | 2000-12-14 17:15:00 | Re: Why vacuum? |