Re: General purpose hashing func in pgbench

From: Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: General purpose hashing func in pgbench
Date: 2018-03-07 13:21:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Teodor,

>> 1) Seems, it's good idea to add credits to Austin Appleby to
>> comments.

Done. Also rebased to the latest master.

> I think that both points refer to the fact that original algorithm
> accepts a byte string as an input, slices it up by 8 bytes and form
> unsigned int values from it. In that case the order of bytes in the
> input string does matter since it may result in different integers on
> different architectures. And it is also fair requirement for a byte
> string to be aligned as some architectures cannot handle unaligned data.
> In this patch though I slightly modified the original algorithm in a way
> that it takes unsigned ints as an input (not byte string), so neither of
> this points should be a problem as it seems to me. But I'll double check
> it on big-endian machine with strict alignment (Sparc).

Turned out that the only big-endian machine I could run test on is out
of order.

Maybe someone has access to a big-endian machine? If so, could you
please run some basic test and send me the resulting file? I've attached
initialization script and pgbench script which could be run as follows:

psql postgres -f hash_init.sql
pgbench postgres -T60 -f hash_run.sql
psql postgres -c "copy abc to '/tmp/hash_results.csv'"


Ildar Musin

Attachment Content-Type Size
hash_init.sql application/x-sql 114 bytes
hash_run.sql application/x-sql 120 bytes
pgbench_hash_v12.patch text/x-diff 13.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-07 13:46:36 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Arthur Zakirov 2018-03-07 13:18:20 Re: [PROPOSAL] Shared Ispell dictionaries