Re: Buffering GiST leaf pages too - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Buffering GiST leaf pages too
Date
Msg-id 4E572F07.4040107@enterprisedb.com
Whole thread Raw
In response to Re: Buffering GiST leaf pages too  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On 26.08.2011 00:45, Jim Nasby wrote:
> I've often wondered about the per-tuple overhead of all kinds of operations, not just GiST index builds. For example,
ifyou're doing a seqscan, ISTM it would be a lot more efficient to memcpy an entire page into backend-local memory and
operateoff of that lock-free.
 

What we currently do is even better than that. We take the lock once, 
and hold it while we do all the visibility checks. Then the lock is 
released, but the page is kept pinned so that it doesn't get evicted 
from the buffer cache. No memcpy() required.

> Similarly for an index scan, you'd want to copy a full leaf page if you think you'll be hitting it more than once or
twice.

We more or less do that too already. When an index scan steps on a leaf 
page, it scans the page for all matches, and copies them to 
backend-local memory. The page lock is then released.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removal of useless include references
Next
From: Jesper Krogh
Date:
Subject: Re: tsvector concatenation - backend crash