From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: General purpose hashing func in pgbench |
Date: | 2018-03-21 15:02:00 |
Message-ID: | 43f6f425-b37a-b8b9-90e8-4ba8aa00fb73@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I finally managed to perform this test on sparc v9 machine which is 64
> bit big-endian architecture. I run pgbench script (see previous message)
> with default_seed=123 on both x86-64 and sparc machines and visualized
> the results. You can find them in the attached chart. Both images showed
> the same distribution. So endianness isn't a concern here.
Agree, pushed.
But I have a notice about number of arguments. Seems, special values for hash
and greatest/least functions is not actually needed. If we split nargs option to
n mandatory arguments and n optional ones then special values for that functions
will go away: hash will have 1 mandatory and 1 optional, greatest/least will
have one mandatory and infinite number of optional. Not sure for now about
CASE/WHEN case. But seems it's a deal for separate refactoring.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-03-21 15:07:57 | Re: pgsql: Fix CommandCounterIncrement in partition-related DDL |
Previous Message | Tomas Vondra | 2018-03-21 14:55:08 | Re: Hash join in SELECT target list expression keeps consuming memory |