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.
I think that this problem has gradually gotten worse as we've added features to the system. Between 7.4 and master, we've added the following stuff to what this function needs to propagate into the RelOptInfo: tablespace, attr_needed, attr_width, allvisfrac, rel_parallel_workers, statlist, serverid, fdwroutine, fkey_list, part_scheme, boundinfo, nparts, partexprs. That's a fair amount of stuff, and IndexOptInfo includes more things now, too. The whole thing seems pretty inefficient. get_relation_statistics() stores a list of statistics object OIDs in the relcache and then, in get_relation_statistics(), builds a StaExtInfo for each one. That, however, means that the StaExtInfo is getting rebuilt for every query. If the RelOptInfo could point directly into the relcache, then we could build that stuff once when the relcache entry was created, or maybe on demand, and then keep it forever. But if we did that today it wouldn't work too well: we'd still have to copy the result from the relcache into the RelOptInfo. The just-copy-it approach is what set_relation_partition_info does for rel->boundinfo, and that similarly seems like a waste of cycles. I have a feeling we're all cargo-culting each new feature into a system that we may have outgrown, but maybe there's some reason behind this that I'm missing. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
