Re: Declarative partitioning

On 4 September 2015 at 06:51, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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