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
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. |