Hi Amit,
> 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.
OK, I'll see what could be done here as well then.
On Tue, Mar 07, 2017 at 10:55:12AM +0900, Amit Langote wrote:
> 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
>
>
--
Best regards,
Aleksander Alekseev
