Re: Relation extension scalability

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Relation extension scalability
Дата
Msg-id CAFiTN-tkYR3S_DdF2U9gQbNi7zUEJdQtgcOVHadBcTeVS+d9_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Relation extension scalability  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Relation extension scalability  (Petr Jelinek <petr@2ndquadrant.com>)
Re: Relation extension scalability  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers

On Mon, Mar 28, 2016 at 3:02 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
1. Relation Size : No change in size, its same as base and v13

2. INSERT 1028 Byte 1000 tuple performance
-----------------------------------------------------------
Client base v13 v15
1 117 124 122
2 111 126 123
4 51 128 125
8 43 149 135
16 40 217 147
32 35 263 141

3. COPY 10000 Tuple performance.
----------------------------------------------
Client base v13 v15
1 118 147 155
2 217 276 273
4 210 421 457
8 166 630 643
16 145 813 595
32 124 985 598

Conclusion:
---------------
1. I think v15 is solving the problem exist with v13 and performance is significantly high compared to base, and relation size is also stable, So IMHO V15 is winner over other solution, what other thinks ?

2. And no point in thinking that V13 is better than V15 because, V13 has bug of sometime extending more than expected pages and that is uncontrolled and same can be the reason also of v13 performing better.

Found one problem with V15, so sending the new version.
In V15 I am taking prev_blkno as targetBlock instead it should be the last block of the relation at that time. Attaching new patch.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Piotr Stefaniak
Дата:
Сообщение: Re: Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Move PinBuffer and UnpinBuffer to atomics