From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Declarative partitioning optimization for large amount of partitions |
Date: | 2017-03-07 01:55:12 |
Message-ID: | b2d42c6f-2bcb-fb13-9c1c-0cf333a50571@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Aleksander,
On 2017/03/07 0:22, Aleksander Alekseev wrote:
> Hello.
>
> 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.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
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 |