On Mon, Feb 6, 2017 at 3:34 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > PartitionScheme is shared across multiple relations, join or base, > partitioned similarly. Obviously it can't and does not need to point > partition bound informations (which should all be same) of all those > base relations. O the the face of it, it looks weird that it points to > only one of them, mostly the one which it encounters first. But, since > it's going to be the same partition bound information, it doesn't > matter which one. So, I think, we can point of any one of those. Do > you agree?
Yes. >> The fact that set_append_rel_size needs to reopen the relation to >> extract a few more bits of information is not desirable. You need to >> fish this information through in some other way; for example, you >> could have get_relation_info() stash the needed bits in the >> RelOptInfo. > > I considered this option and discarded it, since not all partitioned > relations will have OIDs for partitions e.g. partitioned joins will > not have OIDs for their partitions. But now that I think of it, we > should probably store those OIDs just for the base relation and leave > them unused for non-base relations just like other base relation > specific fields in RelOptInfo. Right. >> FRACTION_PARTS_TO_PLAN seems like it should be a GUC. > > +1. Will take care of this. Does "representative_partitions_fraction" > or "sample_partition_fraction" look like a good GUC name? Any other > suggestions? I like the second one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
