Re: RFC: extensible planner state

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> But that still requires the extension to do a lot of bookkeeping just
> for the privilege of storing some per-query private state, and it
> seems to me that you might well want to store some private state
> per-RelOptInfo or possibly per-PlannerInfo, which seems to require an
> even-more-unreasonable amount of effort. An extension might be able to
> spin up a hash table keyed by pointer address or maybe some
> identifying properties of a RelOptInfo, but I think it's going to be
> slow, fragile, and ugly. So what I'd like to propose instead is
> something along the lines of the private-ExplainState-data system:
> http://postgr.es/m/CA+TgmoYSzg58hPuBmei46o8D3SKX+SZoO4K_aGQGwiRzvRApLg@mail.gmail.com
> https://git.postgresql.org/pg/commitdiff/c65bc2e1d14a2d4daed7c1921ac518f2c5ac3d17

This seems generally reasonable to me. I agree that it's slightly
annoying to bloat every RelOptInfo with two more fields, but I don't
see a better alternative to that. In any case, sizeof(RelOptInfo)
is 448 right now on my dev machine; making it 464 isn't going to
change anything.

I wonder if we couldn't get rid of PlannerInfo.join_search_private
in favor of expecting join search hooks to use this mechanism
(thus, GEQO would become an in-core consumer of the mechanism).

Another idea is to get rid of RelOptInfo.fdw_private, although
that has a little more excuse to live in that it's reasonably
clear who gets to use it, namely the FDW supporting the relation.
(Too bad there's no comment explaining that.)

Nitpicks:

* The initial allocations of the arrays need to take
more care than this about which context the arrays go into,
ie it had better be planner_cxt for PlannerInfo or PlannerGlobal,
and the same context the RelOptInfo is in for RelOptInfo.
Otherwise you risk a mess under GEQO.

* Surely, if extension_state etc is read_write_ignore, then
extension_state_allocated etc had better be as well? I don't
understand the rationale for preserving one without the other.

regards, tom lane