Re: heap vacuum & cleanup locks
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-06-06T06:00:15Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make VACUUM avoid waiting for a cleanup lock, where possible.
- bbb6e559c4ea 9.2.0 cited
On Mon, Jun 6, 2011 at 12:19 AM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Sun, Jun 5, 2011 at 12:03, Robert Haas <robertmhaas@gmail.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