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

Reply via email to