Hi Robert, >> > 0007: > >> > This patch introduces code to check if the scanning of default > partition > >> > child > >> > can be skipped if it's constraints are proven. > >> > >> If I understand correctly, this is actually a completely separate > >> feature not intrinsically related to default partitioning. > > > > I don't see this as a new feature, since scanning the default partition > > will be introduced by this series of patches only, and rather than a > > feature this can be classified as a completeness of default skip > > validation logic. Your thoughts? > > Currently, when a partitioned table is attached, we check whether all > the scans can be checked but not whether scans on some partitions can > be attached. So there are two separate things: > > 1. When we introduce default partitioning, we need scan the default > partition either when (a) any partition is attached or (b) any > partition is created. > > 2. In any situation where scans are needed (scanning the partition > when it's attached, scanning the default partition when some other > partition is attached, scanning the default when a new partition is > created), we can run predicate_implied_by for each partition to see > whether the scan of that partition can be skipped. > > Those two changes are independent. We could do (1) without doing (2) > or (2) without doing (1) or we could do both. So they are separate > features. > > In my V25 series(patch 0005) I have only addressed half of (2) above i.e. code to check whether the scan of a partition of default partition can be skipped when other partition is being added. Amit Langote has submitted[1] a separate patch(0003) to address skipping the scan of the children of relation when it's being attached as a partition.
[1] https://www.postgresql.org/message-id/4cd13b03-846d-dc65-89de-1fd9743a3869%40lab.ntt.co.jp Regards, Jeevan Ladhe