Horton

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

View thread View on postgr.es
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, "'Peter Eisentraut'" <peter.eisentraut@2ndquadrant.com>
Cc: "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, "'Simon Riggs'" <simon@2ndquadrant.com>, David Rowley <david.rowley@2ndquadrant.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-04T04:58:12Z
Lists: pgsql-hackers 
Hi,

On 2019/04/04 13:37, Tsunakawa, Takayuki wrote:
> Hi Peter,
> 
> From: Peter Eisentraut [mailto:peter.eisentraut@2ndquadrant.com]
>> I did a bit of performance testing, both a plain pgbench and the
>> suggested test case with 4096 partitions.  I can't detect any
>> performance improvements.  In fact, within the noise, it tends to be
>> just a bit on the slower side.
>>
>> So I'd like to kick it back to the patch submitter now and ask for more
>> justification and performance analysis.
>>
>> Perhaps "speeding up planning with partitions" needs to be accepted first?
> 
> David kindly showed how to demonstrate the performance improvement on March 26, so I changed the status to needs review.  I'd appreciate it if you could continue the final check.

Also, since the "speed up partition planning" patch went in (428b260f8),
it might be possible to see the performance boost even with the
partitioning example you cited upthread.

Thanks,
Amit

Commits

  1. Reorder LOCALLOCK structure members to compact the size

  2. Be more careful to not lose sync in the FE/BE protocol.