Re: Rewriting Free Space Map
От | Heikki Linnakangas |
---|---|
Тема | Re: Rewriting Free Space Map |
Дата | |
Msg-id | 47E2CD7B.3090600@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Rewriting Free Space Map ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas wrote: > Tom Lane wrote: >> "Heikki Linnakangas" <heikki@enterprisedb.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
В списке pgsql-hackers по дате отправления: