Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Дата | |
Msg-id | CAA4eK1K_db+Pu6q=AND5DQtK9nsy9tnuV14+gQ3xRYo7v=kNAA@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Moving relation extension locks out of heavyweight lock manager (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
|
Список | pgsql-hackers |
On Thu, May 11, 2017 at 6:09 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > This work would be helpful not only for existing workload but also > future works like some parallel utility commands, which is discussed > on other threads[1]. At least for parallel vacuum, this feature helps > to solve issue that the implementation of parallel vacuum has. > > I ran pgbench for 10 min three times(scale factor is 5000), here is a > performance measurement result. > > clients TPS(HEAD) TPS(Patched) > 4 2092.612 2031.277 > 8 3153.732 3046.789 > 16 4562.072 4625.419 > 32 6439.391 6479.526 > 64 7767.364 7779.636 > 100 7917.173 7906.567 > > * 16 core Xeon E5620 2.4GHz > * 32 GB RAM > * ioDrive > > In current implementation, it seems there is no performance degradation so far. > I think it is good to check pgbench, but we should do tests of the bulk load as this lock is stressed during such a workload. Some of the tests we have done when we have improved the performance of bulk load can be found in an e-mail [1]. [1] - https://www.postgresql.org/message-id/CAFiTN-tkX6gs-jL8VrPxg6OG9VUAKnObUq7r7pWQqASzdF5OwA%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: