Re: [HACKERS] [WIP] Zipfian distribution in pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] [WIP] Zipfian distribution in pgbench
Date
Msg-id alpine.DEB.2.20.1707201912560.26752@lancre
Whole thread Raw
In response to Re: [HACKERS] [WIP] Zipfian distribution in pgbench  (Alik Khilazhev <a.khilazhev@postgrespro.ru>)
Responses Re: [HACKERS] [WIP] Zipfian distribution in pgbench
List pgsql-hackers
Hello Alik,

>> About the maths: As already said, I'm not at ease with a random_zipfian 
>> function which does not display a (good) zipfian distribution. At the 
>> minimum the documentation should be clear about the approximations 
>> implied depending on the parameter value.
>
> I add one more sentence to documentation to emphasize that degree of 
> proximity depends on parameter .
> And also I made restriction on 
> parameter, now it can be only in range (0; 1)

Hmmm. On second thought, maybe one or the other is enough, either restrict 
the parameter to values where the approximation is good, or put out a 
clear documentation about when the approximation is not very good, but it 
may be still useful even if not precise.

So I would be in favor of expanding the documentation but not restricting 
the parameter beyond avoiding value 1.0.

>> [...]
> Now it prints warning message if array overflowed. To print message only 
> one time, it uses global flag, which is available for all threads. And 
> theoretically message can be printed more than one time. [...]
> So, should I spend time on solving this issue?

No. Just write a comment.

>> If the zipf cache is constant size, there is no point in using dynamic 
>> allocation, just declare an array…
>
> Fixed. Does ZIPF_CACHE_SIZE = 15 is ok?

My guess is yes, till someone complains that it is not the case;-)

>> There should be non regression tests somehow. If the "improve pgbench
>> tap test infrastructure" get through, things should be added there.
>
> I will send tests later, as separate patch.

I think that developping a test would be much simpler with the improved 
tap test infrastructure, so I would suggest to wait to know the result of 
the corresponding patch.

Also, could you recod the patch to CF 2017-09?
https://commitfest.postgresql.org/14/

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [HACKERS] Increase Vacuum ring buffer.
Next
From: Shubham Barai
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)