Re: Improve heapgetpage() performance, overhead from serializable

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Improve heapgetpage() performance, overhead from serializable
Date: 2024-04-08 03:43:12
Message-ID: CAApHDvpbZMDYLN67qZU-zRu=pWxeOePUNq-nUfn54PkF84WQPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 8 Apr 2024 at 15:13, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-08 03:46:42 Re: Use streaming read API in ANALYZE
Previous Message jian he 2024-04-08 03:21:42 Re: remaining sql/json patches