Re: Table Partitioning, Part 1 - Mailing list pgsql-hackers

On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > 1. Embellish inheritance or separate infrastructure?
> 
> > It seems prudent to avoid building on that foundation, even though we
> > may decide to use some similar approaches.
> 
> I disagree.  The code is there, it could use work, and what you are
> basically proposing is to duplicate both the existing work and much
> of the improvement it needs.

Minefields need clearing someday, I suppose. 

Multiple inheritance isn't something I'll be spending time on though.

> > 2. Individual Relations explicitly in the plan or MultiRelation plan
> > nodes? (i.e. is a SeqScan of a Partitioned Table one Node or many
> > nodes?)
> 
> This one is so obvious it hardly requires any discussion.  You cannot
> have intelligent planning if you fold everything into a single plan
> node.  

That was my first thought, and my proposed approach. But many people
have asked for the discussion to be aired, so thats why its mentioned.

Could allow me to complete something useful though basic for 8.1

> I just finished getting rid of a similarly bad decision in the
> context of indexscan planning (ie, a hardwired approach to OR logic)
> --- let's not make that mistake again.

Well, yes, I saw.

...but my problem remains: how do we handle the Partition Elimination
via joins. What do you think of my later discussion on the possibility
of nested loops joins via Multi-indexscans. I don't like that answer,
but it does give us something...can you see a different way?

> > 5. Constraints or specific Partitioning syntax?
> 
> > Partition Elimination relies upon being able to prove at execution time
> 
> You mean plan time.

No, definitely execution time. Estimated only at plan time.

We need to support Bound plans, with constant supplied as parameter. We
also need to support Partition Elimination via restrictions using time-
functions, most of which are Stable functions, which again are not
evaluated until execution time.

Yeh, we might be able to prove it at Plan time, but an implementation
that offered Plan-time-only PE would be too restrictive.

> > that two clauses in a query restriction are always false when taken
> > together. 
> 
> We already have a reasonably decent implementation of such proving for
> partial-index predicate handling.  I see no reason not to use that.
> So I don't agree with the idea of special-purpose syntax or logic.

Oh? Thanks. I wasn't looking forward to that bit...

I'd seen the partial CNF stuff for OR handling and the range clause
identification for clause selectivity.

Many thanks,

Best Regards, Simon Riggs