On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers <e...@xs4all.nl> wrote: >> My bad. The fix I sent last night for one of the cache flush issues >> wasn't quite right. The attached seems to fix it. > Yes, fixed here too. Thanks.
Thanks for the report - that was a good catch. I've committed 0001 - 0006 with that correction and a few other adjustments. There's plenty of room for improvement here, and almost certainly some straight-up bugs too, but I think we're at a point where it will be easier and less error-prone to commit follow on changes incrementally rather than by continuously re-reviewing a very large patch set for increasingly smaller changes. Some notes: * We should try to teach the executor never to scan the parent. That's never necessary with this system, and it might add significant overhead. We should also try to get rid of the idea of the parent having storage (i.e. a relfilenode). * The fact that, in some cases, locking requirements for partitioning are stronger than those for inheritance is not good. We made those decisions for good reasons -- namely, data integrity and not crashing the server -- but it would certainly be good to revisit those things and see whether there's any room for improvement. * I didn't commit 0007, which updates the documentation for this new feature. That patch removes more lines than it adds, and I suspect what is needed here is an expansion of the documentation rather than a diminishing of it. * The fact that there's no implementation of row movement should be documented as a limitation. We should also look at removing that limitation. -- 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
