Re: speedup tidbitmap patch: hash BlockNumber

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: speedup tidbitmap patch: hash BlockNumber
Date: 2014-12-15 13:36:48
Message-ID: 548EE3F0.8040504@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-12-15 13:45:47 Re: Commit fest 2014-12, let's begin!
Previous Message Andres Freund 2014-12-15 13:14:26 Re: GiST kNN search queue (Re: KNN-GiST with recheck)