Re: Optimising compactify_tuples() - Mailing list pgsql-hackers

From David Rowley
Subject Re: Optimising compactify_tuples()
Date
Msg-id CAApHDvosGYgoCXnmrb9PHCrHoLT-=ofWQsr5GVCLcMG0_192Bg@mail.gmail.com
Whole thread Raw
In response to Re: Optimising compactify_tuples()  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Optimising compactify_tuples()  (Thomas Munro <thomas.munro@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Next
From: Peter Eisentraut
Date:
Subject: Re: Allow CURRENT_ROLE in GRANTED BY