Re: heap vacuum & cleanup locks

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: heap vacuum & cleanup locks
Date: 2011-06-06 07:02:40
Message-ID: 4DEC7B90.6000709@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.06.2011 09:35, Jim Nasby wrote:
> I've had a related idea that I haven't looked into... if you're scanning a relation (ie: index scan, seq scan) I've wondered if it would be more efficient to deal with the entire page at once, possibly be making a copy of it. This would reduce the number of times you pin the page (often quite dramatically). I realize that means copying the entire page, but I suspect that would occur entirely in the L1 cache, which would be fast.

We already do that. When an index scan moves to an index page, the heap
tid pointers of all the matching index tuples are copied to
backend-private memory in one go, and the lock is released. And for a
seqscan, the visibility of all the tuples on the page is checked in one
go while holding the lock, then the lock is released but the pin is
kept. The pin is only released after all the tuples have been read.
There's no repeated pin-unpin for each tuple.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-06-06 07:39:56 Re: Vacuum, visibility maps and SKIP_PAGES_THRESHOLD
Previous Message Heikki Linnakangas 2011-06-06 06:54:48 Re: reducing the overhead of frequent table locks - now, with WIP patch