| From: | Alik Khilazhev <a(dot)khilazhev(at)postgrespro(dot)ru> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [WIP] Zipfian distribution in pgbench |
| Date: | 2017-07-21 08:43:31 |
| Message-ID: | E802D02D-8628-4DAF-8A63-44CA2ED03E84@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
I have removed restriction and expanded documentation in attaching patch v5.
Also I have recorded patch to CF 2017-09 — https://commitfest.postgresql.org/14/1206/.
—
Thanks and Regards,
Alik Khilazhev
Postgres Professional:
http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2017-07-21 10:16:13 | Re: Bug in ExecModifyTable function and trigger issues for foreign tables |
| Previous Message | Dean Rasheed | 2017-07-21 08:36:36 | Re: pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b |