Re: speedup tidbitmap patch: hash BlockNumber
От | Heikki Linnakangas |
---|---|
Тема | Re: speedup tidbitmap patch: hash BlockNumber |
Дата | |
Msg-id | 548EE3F0.8040504@vmware.com обсуждение исходный текст |
Ответ на | speedup tidbitmap patch: hash BlockNumber (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: speedup tidbitmap patch: hash BlockNumber
|
Список | pgsql-hackers |
On 10/22/2014 04:14 PM, Teodor Sigaev wrote: > Just replace tag_hash in tidbitmap which uses hash_any to direct call of > hash_uint32, it saves ~5% of execution time. > > An example: > # create extension btree_gin; > # select (v / 10)::int4 as i into t from generate_series(1, 5000000) as v; > # create index idx on t using gin (i); > # set enable_seqscan = off; > > # explain analyze select * from t where i >= 0; > without patch: Execution time: 2427.692 ms > with patch: Execution time: 2319.376 ms > > # explain analyze select * from t where i >= 100 and i<= 100; > without patch: Execution time: 524.441 ms > with patch: Execution time: 504.478 ms Nice little speedup, for such a simple patch. On my laptop, "perf" confirms that with the patch, about 5% of the CPU time is spent in tag_blocknumber, and without it, about 8% is spent in tag_hash. That gives a 3% speed up, which is in the same ballpark that you saw. I'd suggest putting the new function in hashfn.c, where we already have similar functions, string_hash, tag_hash, oid_hash and bitmap_hash. And name it "blocknumber_hash", for consistency. - Heikki
В списке pgsql-hackers по дате отправления: