Re: Buffering GiST leaf pages too

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Buffering GiST leaf pages too
Date: 2011-08-26 05:28:39
Message-ID: 4E572F07.4040107@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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, if you're doing a seqscan, ISTM it would be a lot more efficient to memcpy an entire page into backend-local memory and operate off 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Krogh 2011-08-26 05:34:01 Re: tsvector concatenation - backend crash
Previous Message Tom Lane 2011-08-26 05:07:29 Re: Removal of useless include references