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 |
Date: | 2019-07-24 08:23:44 |
Message-ID: | alpine.DEB.2.21.1907240823060.10384@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Simon,
>> While doing some performance tests and reviewing patches, I needed to
>> create partitioned tables. Given the current syntax this is time
>> consumming.
>
> Good idea. I wonder why we didn't have it already.
Probably because I did not have to create partitioned table for some
testing:-)
>> sh> pgench -i -s 1 --partition-number=$N --partition-type=hash
>
> Given current naming of options, I would call this
> --partitions=number-of-partitions and --partition-method=hash
Ok.
>> # then run
>> sh> pgench -S -M prepared -P 1 -T 10
>>
>> # 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.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-init-partitioned-2.patch | text/x-diff | 9.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2019-07-24 08:27:18 | Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding |
Previous Message | Fabien COELHO | 2019-07-24 07:56:29 | Re: pgbench tests vs Windows |