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

From John Naylor
Subject Re: Improve heapgetpage() performance, overhead from serializable
Date
Msg-id CAFBsxsF+q7x6r+_Qoo48SqWZ8T2wSYRH48Qdrc+UsLvv6fbzkw@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
Re: Improve heapgetpage() performance, overhead from serializable
List pgsql-hackers

On Mon, Jul 17, 2023 at 9:58 PM Andres Freund <andres@anarazel.de> wrote:

> FWIW, there's more we can do, with some hacky changes I got the time down to
> 273.261, but the tradeoffs start to be a bit more complicated. And 397->320ms
> for something as core as this, is imo worth considering on its own.

Nice!

> On 2023-07-17 09:55:07 +0800, Zhang Mingli wrote:

> > Does it make sense to combine if else condition and put it to the incline function’s param?
> >
> > Like:
> > scan->rs_ntuples = heapgetpage_collect(scan, snapshot, page, buffer,
> >                                                                                                  block, lines, all_visible, check_serializable);
>
> I think that makes it less likely that the compiler actually generates a
> constant-folded version for each of the branches. Perhaps worth some
> experimentation.

Combining this way doesn't do so for me.

Minor style nit:

+ scan->rs_ntuples = heapgetpage_collect(scan, snapshot, page, buffer,
+   block, lines, 0, 1);

I believe we prefer true/false rather than numbers. 

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: Thomas Munro
Date:
Subject: Re: old_snapshot_threshold bottleneck on replica