From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: expression evaluation improvements |
Date: | 2021-11-05 17:09:10 |
Message-ID: | CA+TgmoaZNikRZW3AMFwPq5oks2NRXQbYqLz0vp-GfkbkyN8QQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 5, 2021 at 12:48 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't see how that works - the same expression can be evaluated multiple
> times at once, recursively. So you can't have things like FunctionCallInfoData
> shared. One key point of separating out the mutable data into something that
> can be relocated is precisely so that every execution can have its own
> "mutable" data area, without needing to change anything else.
Oh. That makes it harder.
> > Or another option would be: instead of having one giant allocation in which
> > we have to place data of every different type, have one allocation per kind
> > of thing. Figure out how many FunctionCallInfo objects we need and make an
> > array of them. Figure out how many NullableDatum objects we need and make a
> > separate array of those. And so on. Then just use pointers.
>
> Without the relative pointer thing you'd still have pointers into those arrays
> of objects. Which then would make the thing non-shareable.
Well, I guess you could store indexes into the individual arrays, but
then I guess you're not gaining much of anything.
It's a pretty annoying problem, really. Somehow it's hard to shake the
feeling that there ought to be a better approach than relative
pointers.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-11-05 17:20:12 | Re: WIP: expression evaluation improvements |
Previous Message | Robert Haas | 2021-11-05 16:58:04 | Re: removing global variable ThisTimeLineID |