Re: A few more opportunities to use TupleTableSlotOps fields

From: Andres Freund <andres(at)anarazel(dot)de>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A few more opportunities to use TupleTableSlotOps fields
Date: 2019-05-21 16:39:20
Message-ID: 20190521163920.hvibbhmybqrjaoe5@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-05-21 16:47:50 +0200, Antonin Houska wrote:
> 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.

It really can't, without actually fetching tts_ops, and reading the
callback's location. How would e.g. tts_virtual_copyslot() know that the
slot's tts_ops point to TTSOpsVirtual? There's simply no way to express
that in C. If this were a class in C++, the compiler would have decent
chance at it these days (because if it's a final method it can infer
that it has to be, and because whole program optimization allows
devirtualization passes to do so), but well, it's not.

And then there's the whole inlining issue explained in my other recent
mail on the topic.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message PegoraroF10 2019-05-21 17:05:11 Re: Re: Refresh Publication takes hours and doesn´t finish
Previous Message Andres Freund 2019-05-21 16:34:40 Re: A few more opportunities to use TupleTableSlotOps fields