On 2014-12-24 13:58:41 -0600, Jim Nasby wrote:
> This surprises me given that SMHasher shows XXH to be 50% faster than Spooky
> for 20 byte keys.
Note that there's quite some differences in how smhasher and postgres
use the hash functions. The former nearly exclusively exercises the hash
function
Jim Nasby writes:
> On 12/24/14, 10:58 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> FWIW, I don't believe these results for one second. It's quite plausible
>>> that there's a noticeable performance benefit, but a factor of three is
>>> completely unrealistic... Could you please recheck?
>>
On 12/24/14, 10:58 AM, Tom Lane wrote:
Andres Freund writes:
On 2014-12-24 00:27:39 -0600, Jim Nasby wrote:
pgbench -S -T10 -c 4 -j 4
master:
tps = 9556.356145 (excluding connections establishing)
tps = 9897.324917 (excluding connections establishing)
tps = 9287.286907 (excluding connections e
Andres Freund writes:
> On 2014-12-24 00:27:39 -0600, Jim Nasby wrote:
>> pgbench -S -T10 -c 4 -j 4
>> master:
>> tps = 9556.356145 (excluding connections establishing)
>> tps = 9897.324917 (excluding connections establishing)
>> tps = 9287.286907 (excluding connections establishing)
>> tps = 1021
On 2014-12-24 00:27:39 -0600, Jim Nasby wrote:
> pgbench -S -T10 -c 4 -j 4
> master:
> tps = 9556.356145 (excluding connections establishing)
> tps = 9897.324917 (excluding connections establishing)
> tps = 9287.286907 (excluding connections establishing)
> tps = 10210.130833 (excluding connections
On 12/24/14, 12:27 AM, Jim Nasby wrote:
There were several select-only runs on both to warm shared_buffers (set to
512MB for this test, and fsync is off).
BTW, presumably this ~380M database isn't big enough to show any problems with
hash collisions, and I'm guessing you'd need way more memor
On 12/20/14, 2:13 PM, Jim Nasby wrote:
On 12/20/14, 11:51 AM, Tom Lane wrote:
Andres Freund writes:
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
What I am thinking is not using all of those fields in their raw form to
calculate the hash value. IE: something analogous to:
hash_any(SharedBuf
On 12/20/14, 11:51 AM, Tom Lane wrote:
Andres Freund writes:
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
What I am thinking is not using all of those fields in their raw form to
calculate the hash value. IE: something analogous to:
hash_any(SharedBufHash, (rot(forkNum, 2) | dbNode) ^ relNo
Andres Freund writes:
> On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
>> What I am thinking is not using all of those fields in their raw form to
>> calculate the hash value. IE: something analogous to:
>> hash_any(SharedBufHash, (rot(forkNum, 2) | dbNode) ^ relNode) << 32 |
>> blockNum)
>>
>>
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
> I'm not suggesting we change BufferTag or BufferLookupEnt; clearly we
> can't simply throw away any of the fields I was talking about (well,
> except possibly tablespace ID. AFAICT that's completely redundant for
> searching because relid is UNIQUE).
On 12/19/14, 5:13 PM, Tom Lane wrote:
Jim Nasby writes:
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires uint64.
It also occurs to
"k...@rice.edu" writes:
> If we are going to consider changing the hash function, we should
> consider something like xxhash which runs at 13.8GB/s on a 2.7GHz
> x86_64 for the XXH64 variant and 6.8GB/s for the XXH32 variant which
> is double the speed of fast-hash according to the page running on
On Fri, Dec 19, 2014 at 04:41:51PM -0600, Jim Nasby wrote:
> On 12/18/14, 5:00 PM, Jim Nasby wrote:
> >2201582 20 -- Mostly LOCALLOCK and Shared Buffer
>
> Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
> be worth looking at, though it requires uint64.
>
> It also
Jim Nasby writes:
> On 12/18/14, 5:00 PM, Jim Nasby wrote:
>> 2201582 20 -- Mostly LOCALLOCK and Shared Buffer
> Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
> be worth looking at, though it requires uint64.
> It also occurs to me that we're needlessly shoving a
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires uint64.
It also occurs to me that we're needlessly shoving a lot of 0's into the hash
On 12/18/14, 12:48 PM, Tom Lane wrote:
I wrote:
Here's a proposed patch along this line. I left in oid_hash (in the
form of a macro) so that this does not cause any API break for existing
third-party modules. However, no callers in our own code directly
refer to tag_hash or oid_hash anymore.
I wrote:
> Here's a proposed patch along this line. I left in oid_hash (in the
> form of a macro) so that this does not cause any API break for existing
> third-party modules. However, no callers in our own code directly
> refer to tag_hash or oid_hash anymore.
Committed that version after some
Teodor Sigaev writes:
>> -hash_ctl.hash = oid_hash; /* a bit more efficient than tag_hash */
>> +hash_ctl.hash = tag_hash; /* a bit more efficient than tag_hash */
>>
>> I think the comment may need removed here.
> Thank you, fixed
I looked at this patch. It's not right at all here:
+
-hash_ctl.hash = oid_hash; /* a bit more efficient than tag_hash */
+hash_ctl.hash = tag_hash; /* a bit more efficient than tag_hash */
I think the comment may need removed here.
Thank you, fixed
--
Teodor Sigaev E-mail: teo...@sigaev.ru
On 17 December 2014 at 06:07, Teodor Sigaev wrote:
>
> I think this suggestion is misguided, and the patch itself needs
>> rethinking. Instead of doing this, let's hack dynahash.c itself
>> to substitute a shim like this when it's told function == tag_hash and
>> keysize == sizeof(uint32). Then
I think this suggestion is misguided, and the patch itself needs
rethinking. Instead of doing this, let's hack dynahash.c itself
to substitute a shim like this when it's told function == tag_hash and
keysize == sizeof(uint32). Then we can remove any similar shims that
already exist, and possibly
Heikki Linnakangas writes:
> 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.
> I'd suggest putting the new function in hashfn.c, where we already have
> similar functions, str
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, 500) as v;
# create index i
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, 500) as v;
# create index idx on t using gin (i);
# set enable_seqscan
24 matches
Mail list logo
