Re: Improve heapgetpage() performance, overhead from serializable

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Improve heapgetpage() performance, overhead from serializable
Дата
Msg-id CAApHDvpbZMDYLN67qZU-zRu=pWxeOePUNq-nUfn54PkF84WQPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improve heapgetpage() performance, overhead from serializable  (Andres Freund <andres@anarazel.de>)
Ответы Re: Improve heapgetpage() performance, overhead from serializable  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: remaining sql/json patches
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Use streaming read API in ANALYZE