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