On 4 September 2015 at 06:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
> > Sorry about the long delay in replying, to this message or the others > posted in the last few days. I should have notified in advance of my > vacation with rather limited Internet access. No problem, I'm on leave too. > >> The patch does not yet implement any planner changes for partitioned > >> tables, although I'm working on the same and post updates as soon as > >> possible. > ... > > > > This is really the heart of this patch/design. You can work for months on > > all the rest of this, but you will live or die by how the optimization > > works because that is the thing we really need to work well. Previous > > attempts ignored this aspect and didn't get committed. It's hard, perhaps > > even scary, but its critical. It's the 80/20 rule in reverse - 20% of the > > code is 80% of the difficulty. > > > > I suggest you write a partition query test script .sql and work towards > > making this work. Not exhaustive and weird tests, but 5-10 key queries > that > > need to be optimized precisely and quickly. I'm sure that's been done > > before. > > > > Yes, I am working on this and hope to have something to show soon. No rush, no pressure; lets get this right. > > > > I couldn't see why you invented a new form of Alter Table recursion. > > > > It was intended to keep the ALTER TABLE considerations for inherited > tables (and typed tables) separate from those for partitioned tables. > But... > > This begs a larger question that I did not try to answer in this > design/patch - for partitions, do we need to have any catalog entries > other than the pg_class tuple? Everything should start from the requirements of the optimization approach. Once we have that clear, we can confirm other requirements. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
