Re: Improve heapgetpage() performance, overhead from serializable

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Improve heapgetpage() performance, overhead from serializable
Дата
Msg-id 20240408031301.usibofqnd5egw6tl@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Improve heapgetpage() performance, overhead from serializable  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Improve heapgetpage() performance, overhead from serializable  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Hi,

On 2024-04-08 14:43:21 +1200, David Rowley wrote:
> On Sun, 7 Apr 2024 at 19:30, Andres Freund <andres@anarazel.de> wrote:
> > Good call. Added and pushed.
> 
> I understand you're already aware of the reference in the comment to
> heapgetpage(), which no longer exists as of 44086b097.

Yea, https://postgr.es/m/20240407172615.cocrsvboqm3ttqe4%40awork3.anarazel.de


> Melanie and I had discussed the heap_prepare_pagescan() name while I
> was reviewing that recent refactor. Aside from fixing the comment, how
> about also renaming heapgetpage_collect() to
> heap_prepare_pagescan_tuples()?

> Patch attached for reference. Not looking for any credit.
> 
> I'm also happy to revisit the heap_prepare_pagescan() name and call
> heapgetpage_collect() some appropriate derivative of whatever we'd
> rename that to.

I kinda don't like heap_prepare_pagescan(), but heapgetpage() is worse. And I
don't have a great alternative suggestion.

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.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Improve heapgetpage() performance, overhead from serializable
Следующее
От: jian he
Дата:
Сообщение: Re: remaining sql/json patches