From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heap vacuum & cleanup locks |
Date: | 2011-06-06 06:00:15 |
Message-ID: | BANLkTikbu4qaA4-9jjF-s1-2rdmsCh-S_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Sun, Jun 5, 2011 at 12:03, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> If other buffer pins do exist, then we can't
>> defragment the page, but that doesn't mean no useful work can be done:
>> we can still mark used line pointers dead, or dead line pointers
>> unused. We cannot defragment, but that can be done either by the next
>> VACUUM or by a HOT cleanup.
>
> This is just an idea -- Is it possible to have copy-on-write techniques?
> VACUUM allocates a duplicated page for the pinned page, and copy valid
> tuples into the new page. Following buffer readers after the VACUUM will
> see the cloned page instead of the old pinned one.
Heikki suggested the same thing, and it's not a bad idea, but I think
it would be more work to implement than what I proposed. The caller
would need to be aware that, if it tries to re-acquire a content lock
on the same page, the offset of the tuple within the page might
change. I'm not sure how much work would be required to cope with
that possibility.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2011-06-06 06:35:13 | Re: heap vacuum & cleanup locks |
Previous Message | Dan Ports | 2011-06-06 05:58:08 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |