Hi,
On 2018-06-05 15:08:33 -0400, Peter Eisentraut wrote:
> On 6/5/18 13:29, Andres Freund wrote:
> > Besides the change here, I think we should also go much further with the
> > conversion to NullableDatum. There's two main areas of change: I want
> > to move the execExpr.c related code so steps return data into
> > NullableDatums - that removes a good chunk of pointer dereferences and
> > allocations. Secondly I think we should move TupleTableSlot to this
> > format - the issue with nulls / datums being on separate cachelines is
> > noticeable in profiles, but more importantly the code looks more
> > consistent with it.
>
> There are also a variety of utility functions that return a Datum and
> have an extra bool *isnull argument.
I was thinking of, for now at least, not touching those.
> What are your thoughts on using NullableDatum more in those cases? Is
> returning structs a problem for low-level performance?
It vastly depends on architecture, compiler and ABI. It'd be a lot
better if we were using C++ (because the caller reserves the space for
such things, and then it's basically free, see return value optimization
/ copy elision). Thus I'm not wild in immediately changing all of them.
I think there aren't that many that aren't performance critical however,
so I guess an argument could be made to change this regardless.
Greetings,
Andres Freund