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: | Raw Message | Whole Thread | 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? |