Skip site navigation (1) Skip section navigation (2)

Re: rtree: improve performance, tuple killing

From: Neil Conway <neilc(at)samurai(dot)com>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: rtree: improve performance, tuple killing
Date: 2005-01-18 05:43:40
Message-ID: 1106027020.22946.140.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
Barring any objections, I intend to apply this patch tomorrow. The
patch, as well as the original -patches email, are included below.

-Neil

On Wed, 2004-11-24 at 11:15 +1100, Neil Conway wrote:
> This patch makes some improvements to the rtree index implementation:
> 
> (1) Keep a pin on the scan's current buffer and mark buffer. This avoids
> the need to do a ReadBuffer() for each tuple produced by the scan.
> 
> (2) Convert a ReleaseBuffer() ; ReadBuffer() pair into
> ReleaseAndReadBuffer(). Surely not a huge win, but it saves a lock
> acquire/release...
> 
> (3) Remove a bunch of duplicated code in rtget.c; make rtnext() handle
> both the "initial result" and "subsequent result" cases.
> 
> (4) Add support for index tuple killing
> 
> (5) Remove rtscancache(): it is dead code, for the same reason that
> gistscancache() is dead code (an index scan ought not be invoked with
> NoMovementScanDirection).
> 
> The end result is about a 10% improvement in index scan performance,
> according to contrib/rtree_gist/bench.
> 
> These changes (with the exception of #2) are analogous to changes I've
> already made for GiST (it's clear that GiST was started as a fork of
> rtree). I'm not hugely interested in further improvements to rtree; I
> just did this stuff because it is low-hanging fruit and I've already
> made the same changes for GiST.


Attachment: rtree_perf_work-2.patch
Description: text/x-patch (12.6 KB)

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2005-01-18 05:54:31
Subject: Re: transformExpr() refactor
Previous:From: Neil ConwayDate: 2005-01-18 05:15:57
Subject: Re: transformExpr() refactor

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group