Robert Haas <robertmhaas@gmail.com> writes:
> Is there some good reason why get_relation_info() copies all of the
> data that will be needed later in planning into the RelOptInfo instead
> of just storing a pointer to the Relation directly into the
> RelOptInfo? Of course, if we did that, then it would have to leave
> the relation open instead of closing it, and similarly for the
> indexes, but so what? As far as I understand it, we're keeping a lock
> on the relation, so none of this stuff should be able to change under
> it, and pointing to data is faster than copying it.
We are not keeping a lock strong enough to prevent the relcache entry
from changing altogether, e.g. an ANALYZE could commit midway through
and change, say, the relpages/reltuples info. The consequences of
that for consistent planner behavior are not clear to me, but they're
probably not something to dismiss out of hand.
Also, there's a big difference between the entry's contents being
logically unchanging and being physically unchanging: we could get a
relcache inval event that forces a rebuild, and only very limited parts of
the entry are guaranteed not to move around if that happens. There's a
general rule that code outside the relcache shouldn't keep pointers to
most parts of a relcache entry's infrastructure, and for those parts where
we do provide a guarantee (like the tupdesc), it doesn't come for free.
Maybe the planner's uses of the info wouldn't be any more dangerous than
anything else's, but again it's not clear.
I'm disinclined to monkey with the way this works without someone
presenting hard evidence that it creates enough of a performance problem
to be worth spending a significant amount of time changing it. Up to
now I don't think I've ever noticed plancat.c being a large fraction
of planner runtime, though of course that might depend on the test case.
regards, tom lane