Re: A few more opportunities to use TupleTableSlotOps fields - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: A few more opportunities to use TupleTableSlotOps fields
Date
Msg-id 4165.1558450070@spoje.net
Whole thread Raw
In response to Re: A few more opportunities to use TupleTableSlotOps fields  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: A few more opportunities to use TupleTableSlotOps fields  (Robert Haas <robertmhaas@gmail.com>)
Re: A few more opportunities to use TupleTableSlotOps fields  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:

> On Tue, May 21, 2019 at 8:02 AM Antonin Houska <ah@cybertec.at> wrote:
> > Perhaps it's just a matter of taste, but I think the TupleTableSlotOps
> > structure, once initialized, should be used wherever possible. At least for me
> > personally, when I read the code, the particular callback function name is a
> > bit disturbing wherever it's not necessary.
>
> But it's significantly more efficient.

Do you refer to the fact that for example the address of

    tts_virtual_clear(dstslot);

is immediately available in the text section while in this case

    dstslot->tts_ops->clear(dstslot);

the CPU first needs to fetch the address of tts_ops and also that of the
->clear function?

I admit I didn't think about this problem. Nevertheless I imagine that due to
constness of the variables like TTSOpsVirtual (and due to several other const
declarations) the compiler might be able to compute the address of the
tts_ops->clear() expression. Thus the only extra work for the CPU would be to
fetch tts_ops from dstslot, but that should not be a big deal because other
fields of dstslot are accessed by the surrounding code (so all of them might
be available in the CPU cache).

I don't pretend to be an expert in this area though, it's possible that I
still miss something.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel Append subplan order instability on aye-aye
Next
From: Andres Freund
Date:
Subject: Re: VACUUM fails to parse 0 and 1 as boolean value