Re: unnecessary code in_bt_split - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: unnecessary code in_bt_split
Date
Msg-id 1217836077.3934.312.camel@ebony.t-mobile.de.
Whole thread Raw
In response to Re: unnecessary code in_bt_split  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 2008-08-03 at 19:44 -0400, Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > I found that _bt_split function calls PageGetTempPage, but next call is 
> > _bt_page_init which clear all contents anyway. Is there any reason to call 
> > PageGetTempPage instead of palloc?
> 
> Not violating a perfectly good abstraction?
> 
> I agree that PageGetTempPage isn't amazingly efficient, but internal
> refactoring would halve its cost; and if you have some evidence that
> there's a real performance issue then we could think about adjusting
> the temp-page API to allow _bt_pageinit to be combined with it.  But
> I have a real problem with hacking up _bt_split so that it will call
> PageRestoreTempPage on something it didn't get from PageGetTempPage.
> 
> Considering the WAL and regular I/O that will be induced by a split,
> I kinda doubt this is even worth worrying about anyway...

Improving this should help, since the existing page is write locked
during _bt_split. The I/O won't happen at the point that these blocks
are critical contention points.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: "Ryan Bradetich"
Date:
Subject: Initial Unsigned Integer data type performance test results.
Next
From: daveg
Date:
Subject: Re: Mini improvement: statement_cost_limit