|From:||Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>|
|Subject:||Re: General purpose hashing func in pgbench|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 1) Seems, it's good idea to add credits to Austin Appleby to
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
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'"
|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|