On 29 January 2014 06:43, Tom Lane <t...@sss.pgh.pa.us> wrote: > Actually though, isn't this issue mostly about inheritance of a query > *target* table?
Exactly. IMHO updateable views on inheritance sets will have multiple other performance problems, so trying to support them here will not make their usage seamless. We allowed updateable views to work with restrictions in earlier releases, so I can't see why continuing with a much reduced restriction would be a problem in this release. We don't need to remove the remaining restriction all in one release, so we? > Moving that expansion to the rewriter is a totally > different and perhaps more tractable change. It's certainly horribly ugly > as it is; hard to see how doing it at the rewriter could be worse. I see the patch adding some changes to inheritance_planner that might well get moved to rewriter. As long as the ugliness all stays in one place, does it matter where that is -- for this patch -- ? Just asking whether moving it will reduce the net ugliness of our inheritance support. @Craig: I don't think this would have much effect on partitioning performance. The main cost of that is constraint exclusion, which we wuld still perform only once. All other copying and re-jigging still gets performed even for excluded relations, so doing it earlier wouldn't hurt as much as you might think. @Dean: If we moved that to rewriter, would expand_security_quals() and preprocess_rowmarks() also move? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
