Heikki Linnakangas wrote:
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
