Re: make BufferGetBlockNumber() a macro

From: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: make BufferGetBlockNumber() a macro
Date: 2002-04-02 03:10:03
Message-ID: 20020401221003.029cd761.nconway@klamath.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Mon, 01 Apr 2002 20:50:27 -0500
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> writes:
> > C's information hiding is weak enough that you need to rely on the
> > client programmer to exercise good judgement anyway;
>
> This is not a good argument for making the hiding even weaker. I still
> object to this patch.

Even if it were modified to just move the BufferDesc structure into
storage/bufmgr.h?

> It would be interesting to try to understand *why* BufferGetBlockNumber
> is showing up so high in your profile;

It's showing up "high" in the sense that it's being called a lot of
times (2.5 million); each call, of course, is fast, and is dominated
by other parts of the profile (I just sent in the patch since I thought
it was an easy way to improve the performance a little bit).

> Do you have call counts by caller?

Yes, I have the full output of gprof. I didn't send it along since it's
~400 KB; if you're interested, let me know.

> What exactly was the test case, anyway?

I created a table with a single TEXT column; I copied the contents of
/usr/share/dict/words into the column, 4 times. I then quit the session
and started a new one in which I created a hash index on the column,
and ran gprof on the resulting profile data.

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Nicolas Bazin 2002-04-02 04:34:01 please apply patch
Previous Message Tom Lane 2002-04-02 01:50:27 Re: make BufferGetBlockNumber() a macro