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/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
