Re: General purpose hashing func in pgbench
| От | Ildar Musin |
|---|---|
| Тема | Re: General purpose hashing func in pgbench |
| Дата | |
| Msg-id | 7b1b71c7-e308-b39f-e386-d6d67d276071@postgrespro.ru обсуждение |
| Ответ на | Re: General purpose hashing func in pgbench (Ildar Musin <i.musin@postgrespro.ru>) |
| Ответы |
Re: General purpose hashing func in pgbench
|
| Список | 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'" Thanks! -- Ildar Musin i.musin@postgrespro.ru
Вложения
В списке pgsql-hackers по дате отправления: