| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Variable-length FunctionCallInfoData |
| Date: | 2018-06-05 19:08:33 |
| Message-ID: | 0ef82301-49b5-f56e-f626-c304379ebed0@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. What are your thoughts on using
NullableDatum more in those cases? Is returning structs a problem for
low-level performance?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2018-06-05 19:12:08 | Re: Code of Conduct plan |
| Previous Message | Benjamin Scherrey | 2018-06-05 19:06:24 | Re: Code of Conduct plan |