Re: pgbench test failing on 14beta1 on Debian/i386
От | Fabien COELHO |
---|---|
Тема | Re: pgbench test failing on 14beta1 on Debian/i386 |
Дата | |
Msg-id | alpine.DEB.2.22.394.2105191629560.536342@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench test failing on 14beta1 on Debian/i386 (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | pgsql-hackers |
>>>> Or, (3) remove this test? I am not quite sure what there is to gain >>>> with this extra test considering all the other tests with permute() >>>> already present in this script. >>> >>> Yes, I think removing the test is the best option. It was originally >>> added because there was a separate code path for larger permutation >>> sizes that needed testing, but that's no longer the case so the test >>> really isn't adding anything. >> >> Hmmm… >> >> It is the one test which worked in actually detecting an issue, so I would >> not say that it is not adding anything, on the contrary, it did prove its >> value! The permute function is expected to be deterministic on different >> platforms and architectures, and it is not. >> > > In fact what it demonstrates is that the results from permute(), like > all the other pgbench random functions, will vary by platform for > sufficiently large size parameters. Indeed, it is the case if the underlying math use doubles & large numbers. For integer-only computations it should be safe though, and permute should be in this category. >> I'd agree with a two phases approach: drop the test in the short term and >> deal with the PRNG later. I'm sooooo unhappy with this 48 bit PRNG that I >> may be motivated enough to attempt to replace it, or at least add a better >> (faster?? larger state?? same/better quality?) alternative. > > I don't necessarily have a problem with that provided the replacement > is well-chosen and has a proven track record (i.e., let's not invent > our own PRNG). Yes, obviously, I'm not daft enough to reinvent a PRNG. The question is to chose one, motivate the choice, and build the relevant API for what pg needs, possibly with some benchmarking. > For now though, I'll go remove the test. This also removes the reminder… -- Fabien.
В списке pgsql-hackers по дате отправления: