On Tue, Feb 6, 2018 at 9:40 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > I think we can do that for MERGE too, assuming we actually understand > > (1) why each of the pieces is missing > > (2) what would it take to make it work
Right, I completely agree with that. For example, if we find that a certain thing can't be supported without implementing global indexes on partitions, then I have no problem saying "OK, that's not going to be supported", because global indexes are a huge project unto themselves. That's the same reason ON CONFLICT .. UPDATE isn't supported on partitioned tables, and it's just as reasonable for this patch as it is for that one. What we don't want is things that this patch doesn't support because it would take a couple of days of work and the people who wrote the patch were busy and didn't have a couple of extra days. We routinely expect patch authors to plug gaps caused by oversight or lack of round tuits, and this patch should be held to the same standard. In short, we don't have a hard and fast rule that every feature must work with every other feature, but when it doesn't, the burden is on the patch author to justify why that omission is reasonable. I know I expended a lot of ink explaining why parallel query couldn't reasonably be made to support writes. > I plan to go through the patch and this thread over the couple of days, > and summarize what the current status is (or my understanding of it). > That is (a) what are the missing pieces, (b) why are they missing, (c) > how we plan to address them in the future and (d) opinions on these > issues expressed by others on this thread. Thank you. That sounds fantastic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company