Re: [PERFORM] pgbench to the MAXINT
От
Greg Smith
Тема
Re: [PERFORM] pgbench to the MAXINT
Дата
Msg-id
4D549E92.4010709@2ndquadrant.com
Ответ на
Re: [PERFORM] pgbench to the MAXINT (Stephen Frost)
Список
Дерево обсуждения
Re: [PERFORM] pgbench to the MAXINT Tom Lane <tgl@sss.pgh.pa.us>
Re: [PERFORM] pgbench to the MAXINT Stephen Frost <sfrost@snowman.net>
Re: [PERFORM] pgbench to the MAXINT Robert Haas <robertmhaas@gmail.com>
Re: [PERFORM] pgbench to the MAXINT Greg Smith <greg@2ndquadrant.com>
Re: [PERFORM] pgbench to the MAXINT Tom Lane <tgl@sss.pgh.pa.us>
Re: [PERFORM] pgbench to the MAXINT Gurjeet Singh <singh.gurjeet@gmail.com>
Re: [PERFORM] pgbench to the MAXINT Satoshi Nagayasu <snaga@uptime.jp>
Re: [PERFORM] pgbench to the MAXINT Gurjeet Singh <singh.gurjeet@gmail.com>
Re: [PERFORM] pgbench to the MAXINT Heikki Linnakangas <hlinnakangas@vmware.com>
Stephen Frost wrote: > Just wondering, did you consider just calling random() twice and > smashing the result together..? > I did. The problem is that even within the 32 bits that random() returns, it's not uniformly distributed. Combining two of them isn't really going to solve the distribution problem, just move it around. Some number of lower-order bits are less random than the others, and which they are is implementation dependent. Poking around a bit more, I just discovered another possible approach is to use erand48 instead of rand in pgbench, which is either provided by the OS or emulated in src/port/erand48.c That's way more resolution than needed here, given that 2^48 pgbench accounts would be a scale of 2.8M, which makes for a database of about 42 petabytes. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
В списке pgsql-hackers по дате отправления
От: Alex Hunsaker
Дата:
От: Robert Haas
Дата: