On Mon, Dec 11, 2017 at 5:00 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 11 December 2017 at 21:39, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> I don't see much difference in the old and new wording. The word >> "generally" confuses more than clarifying the cases when the planning >> cost curves do not change with the number of relations i.e. >> partitions. > > I added that to remove the false claim that inheritance children don't > make the join problem more complex. This was only true before we had > partition-wise joins. > > I've re-read my original patch and I don't really see the problem with > it. The comment is talking about inheritance child relations, which > you could either interpret to mean INHERITS (sometable), or some table > listed in pg_inherits. The statement that I added forces me into > thinking of the former rather than the latter, so I don't really see > any issue. > > I'm going to leave it here. I don't want to spend too much effort > rewording a comment. My vote is for the original patch I sent. I only > changed it because Robert complained that technically an inheritance > child could actually be a partition.
I basically feel like we're not really solving any problem by changing this. I mean, partition-wise join makes this statement less true, but adding the word "generally" doesn't really help anybody understand the situation better. If we're going to add anything here, I think it should be something like: (This might need to be rethought in light of partition-wise join.) If that's more specific than we want to get, then let's just leave it alone. Partition-wise join isn't even enabled by default at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company