Re: General purpose hashing func in pgbench
От | Ildar Musin |
---|---|
Тема | Re: General purpose hashing func in pgbench |
Дата | |
Msg-id | 6e47c84a-d42a-0e08-1b0d-33e6a6c87778@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 Fabien, 11/01/2018 19:21, Ildar Musin пишет: > > 10/01/2018 21:42, Fabien COELHO пишет: >> Hmm. I do not think that we should want a shared seed value. The seed >> should be different for each call so as to avoid undesired >> correlations. If wanted, correlation could be obtained by using an >> explicit identical seed. >> >> ISTM that the best way to add the seed is to call random() when the >> second arg is missing in make_func. Also, this means that the executor >> would always get its two arguments, so it would simplify the code there. >> > Ok, I think I understand what you meant. You meant the case like following: > > \set x random(1, 100) > \set h1 hash(:x) > \set h2 hash(:x) -- will have different seed from h1 > > so that different instances of hash function within one script would > have different seeds. Yes, that is a good idea, I can do that. > Added this feature in attached patch. But on a second thought this could be something that user won't expect. For example, they may want to run pgbench with two scripts: - the first one updates row by key that is a hashed random_zipfian value; - the second one reads row by key generated the same way (that is actually what YCSB workloads A and B do) It feels natural to write something like this: \set rnd random_zipfian(0, 1000000, 0.99) \set key abs(hash(:rnd)) % 1000 in both scripts and expect that they both would have the same distribution. But they wouldn't. We could of course describe this implicit behaviour in documentation, but ISTM that shared seed would be more clear. Thanks! -- Ildar Musin Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: