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'"
Thanks!
--
Ildar Musin
[email protected]
