|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>|
|Subject:||Re: Declarative partitioning optimization for large amount of partitions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2017/03/07 0:22, Aleksander Alekseev wrote:
> OK, here is a patch.
> Benchmark, before:
> number of transactions actually processed: 1823
> latency average = 1153.495 ms
> latency stddev = 154.366 ms
> tps = 6.061104 (including connections establishing)
> tps = 6.061211 (excluding connections establishing)
> Benchmark, after:
> number of transactions actually processed: 2462
> latency average = 853.862 ms
> latency stddev = 112.270 ms
> tps = 8.191861 (including connections establishing)
> tps = 8.192028 (excluding connections establishing)
> +35% TPS, just as expected. Feel free to run your own benchmarks on
> different datasets and workloads. `perf top` shows that first bottleneck
> is completely eliminated.
That seems like a good gain.
> I did nothing about the second bottleneck
> since as Amit mentioned partition-pruning should solve this anyway and
> apparently any micro-optimizations don't worth an effort.
Sorry, I didn't mean to dissuade you from trying those
micro-optimizations. If general inheritance cases can benefit from it
(which, until we have a different method, will be used by partitioned
tables as well), I think we should try it.
|Next Message||Amit Langote||2017-03-07 01:56:31||Re: Partitioned tables and relfilenode|
|Previous Message||Michael Paquier||2017-03-07 01:49:48||Re: WARNING: relcache reference leak: relation "p1" not closed|