Re: unnecessary code in_bt_split

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unnecessary code in_bt_split
Date: 2008-08-04 07:47:57
Message-ID: 1217836077.3934.312.camel@ebony.t-mobile.de.
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Sun, 2008-08-03 at 19:44 -0400, Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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.com
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message daveg 2008-08-04 07:50:40 Re: Mini improvement: statement_cost_limit
Previous Message Ryan Bradetich 2008-08-04 07:35:37 Initial Unsigned Integer data type performance test results.