|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Simon Riggs <simon(at)2ndquadrant(dot)com>|
|Cc:||PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: pgbench - allow to create partitioned tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>>> # and look at latency:
>>> # no parts = 0.071 ms
>>> # 1 hash = 0.071 ms (did someone optimize this case?!)
>>> # 2 hash ~ 0.126 ms (+ 0.055 ms)
>>> # 50 hash ~ 0.155 ms
>>> # 100 hash ~ 0.178 ms
>>> # 150 hash ~ 0.232 ms
>>> # 200 hash ~ 0.279 ms
>>> # overhead ~ (0.050 + [0.0005-0.0008] * nparts) ms
>> It is linear?
> Good question. I would have hoped affine, but this is not very clear on these
> data, which are the median of about five runs, hence the bracket on the slope
> factor. At least it is increasing with the number of partitions. Maybe it
> would be clearer on the minimum of five runs.
Here is a fellow up.
On the minimum of all available runs the query time on hash partitions is
0.64375 nparts + 118.30979 (in µs).
So the overhead is about 47.30979 + 0.64375 nparts, and it is indeed
pretty convincingly linear as suggested by the attached figure.
|Next Message||David Rowley||2019-07-24 22:36:26||Re: Statistical aggregate functions are not working with PARTIAL aggregation|
|Previous Message||Peter Geoghegan||2019-07-24 22:06:13||Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.|