2010/10/7 Robert Haas <robertmhaas@gmail.com>:
> Well, you can't just arbitrarily turn a O(n) algorithm into an O(lg n)
That's trivially true. I was not asking for the recipe to do it.
> algorithm. I think the most promising approach to scaling to large
> numbers of partitions is the patch that Itagaki Takahiro was working
> on back in July. Unfortunately, that patch still needs a lot of work
> - and some redesign - before it will really meet our needs. Right
> now, the way to set up partitioning is to create a parent table and
> then create a bunch of child tables that inherit from them and then
> put mutually exclusive CHECK constraints on all the children and make
> sure constraint_exclusion is on so that the planner can notice when
> not all children need to be scanned. As a totally general
> architecture, this is probably hard to beat (or to make sublinear).
This is exactly what's described into the official documentation.
Everyone I ask information about before going deeper in test I get
the same answer: don't try to use more than a dozen child tables.
> However, if we have DDL that allows the user to say: this is a set of
> child tables that are range partitions on this key column, with these
> boundaries, then you should be able to make the constraint exclusion
> calculations much more efficient, because it won't have to infer so
> much from first principles. O(lg n) doesn't seem out of the question
> given that architecture.
I see the main problem in the way the planner "understands" which partition
is useful and which one is not.
Having the DDL supporting the feature could just be syntactic sugar
if the underlying mechanism is inadequate.
> I think, though, that that is still some way off. If you're in a
> position to help with (or fund) the coding, it can be made to happen
> faster, of course.
This is why I was asking for directions: brwosing the whole code to look for the
relevant stuff is quite time consuming.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS
