Re: Optimising compactify_tuples()

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Optimising compactify_tuples()
Дата
Msg-id CAApHDvosGYgoCXnmrb9PHCrHoLT-=ofWQsr5GVCLcMG0_192Bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimising compactify_tuples()  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Optimising compactify_tuples()
Список pgsql-hackers
On Fri, 11 Sep 2020 at 01:45, David Rowley <dgrowleyml@gmail.com> wrote:
> I've attached v4b (b is for backwards since the traditional backwards
> tuple order is maintained). v4b seems to be able to run my benchmark
> in 63 seconds. I did 10 runs today of yesterday's v3 patch and got an
> average of 72.8 seconds, so quite a big improvement from yesterday.

After reading the patch back again I realised there are a few more
things that can be done to make it a bit faster.

1. When doing the backup buffer, use code to skip over tuples that
don't need to be moved at the end of the page and only memcpy() tuples
earlier than that.
2. The position that's determined in #1 can be used to start the
memcpy() loop at the first tuple that needs to be moved.
3. In the memmove() code for the preorder check, we can do a similar
skip of the tuples at the end of the page that don't need to be moved.

I also ditched the #ifdef'd out code as I'm pretty sure #1 and #2 are
a much better way of doing the backup buffer given how many tuples are
likely to be skipped due to maintaining the traditional tuple order.

That gets my benchmark down to 60.8 seconds, so 2.2 seconds better than v4b.

I've attached v6b and an updated chart showing the results of the 10
runs I did of it.

David

Вложения

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Allow CURRENT_ROLE in GRANTED BY