From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimising compactify_tuples() |
Date: | 2020-09-10 15:53:22 |
Message-ID: | CAApHDvosGYgoCXnmrb9PHCrHoLT-=ofWQsr5GVCLcMG0_192Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 11 Sep 2020 at 01:45, David Rowley <dgrowleyml(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
image/png | 48.5 KB | |
compactify_tuples_dgr_v6b.patch | application/octet-stream | 8.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-09-10 16:21:54 | Re: Allow CURRENT_ROLE in GRANTED BY |
Previous Message | Masahiko Sawada | 2020-09-10 15:37:03 | Re: Transactions involving multiple postgres foreign servers, take 2 |