From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, 'Simon Riggs' <simon(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Date: | 2019-03-25 10:44:26 |
Message-ID: | 384e1c2f-464a-eeb4-e951-3fd8161a2147@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-03-19 16:38, Peter Eisentraut wrote:
> On 2019-03-19 10:21, Tsunakawa, Takayuki wrote:
>> From: Tsunakawa, Takayuki [mailto:tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com]
>>> Fixed.
>>
>> Rebased on HEAD.
>
> I have committed the first patch that reorganizes the struct. I'll have
> to spend some time evaluating the performance impact of the second
> patch, but it seems OK in principle. Performance tests from others welcome.
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?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2019-03-25 10:48:00 | Re: libpq compression |
Previous Message | David Steele | 2019-03-25 10:38:56 | Re: libpq compression |