Re: Improve heapgetpage() performance, overhead from serializable - Mailing list pgsql-hackers

From David Rowley
Subject Re: Improve heapgetpage() performance, overhead from serializable
Date
Msg-id CAApHDvpbZMDYLN67qZU-zRu=pWxeOePUNq-nUfn54PkF84WQPw@mail.gmail.com
Whole thread Raw
In response to Re: Improve heapgetpage() performance, overhead from serializable  (Andres Freund <andres@anarazel.de>)
Responses Re: Improve heapgetpage() performance, overhead from serializable
List pgsql-hackers
On Mon, 8 Apr 2024 at 15:13, Andres Freund <andres@anarazel.de> wrote:
> I kinda don't like heap_prepare_pagescan(), but heapgetpage() is worse. And I
> don't have a great alternative suggestion.

It came around from having nothing better.  I was keen not to have the
name indicate it was only for checking visibility as we're also
checking for serialization conflicts and pruning the page.  The word
"prepare" made it there as it seemed generic enough to not falsely
indicate it was only checking visibility.  Also, it seemed good to
keep it generic as if we one day end up with something new that needs
to be done before scanning a page in page mode then that new code is
more likely to be put in the function with a generic name rather than
a function that appears to be named for some other unrelated task.  It
would be nice not to end up with two functions to call before scanning
a page in page mode.

> Off-list Melanie suggested heap_page_collect_visible_tuples(). Given the
> separate callsites (making long names annoying) and the fact that it's really
> specific to one caller, I'm somewhat inclined to just go with
> collect_visible_tuples() or page_collect_visible(), I think I prefer the
> latter.

I understand wanting to avoid the long name.  I'd rather stay clear of
"visible", but don't feel as strongly about this as it's static.

David



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: remaining sql/json patches
Next
From: Thomas Munro
Date:
Subject: Re: Use streaming read API in ANALYZE