Re: Rewriting Free Space Map

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rewriting Free Space Map
Date: 2008-03-20 20:47:55
Message-ID: 47E2CD7B.3090600@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>>> I also wonder what the performance impact of extending BufferTag is.
>>
>> That's a fair objection, and obviously something we'd need to check.
>> But I don't recall seeing hash_any so high on any profile that I think
>> it'd be a big problem.
>
> I do remember seeing hash_any in some oprofile runs. But that's fairly
> easy to test: we don't need to actually implement any of the stuff,
> other than add a field to BufferTag, and run pgbench.

I tried that. hash_any wasn't significant on pgbench, but I was able to
construct a test case where it is. It goes like this:

BEGIN;
CREATE TEMPORARY TABLE foo (id int4);
INSERT INTO foo SELECT a FROM generate_series(1, 10000) a;
INSERT INTO foo SELECT * FROM foo;
INSERT INTO foo SELECT * FROM foo;
INSERT INTO foo SELECT * FROM foo;
... (repeat multiple times)

oprofile says that hash_any consumes ~7 % of CPU time on that test on my
laptop.

More precisely, on CVS HEAD it takes between 7.1-7.2%. After extending
BufferTag with one uint32, it takes 7.4-7.5%. So the effect is
measurable if you try hard enough, but not anything to get worried about.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kurt Roeckx 2008-03-20 20:51:05 gcc 4.3 breaks ContribCheck in 8.2 and older.
Previous Message Jeroen T. Vermeulen 2008-03-20 20:13:41 Re: Patch to update libpqxx's homepage in README