On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> I agree that this is being seen the wrong way around. The planner
> contains things it should not do, and as a result we are now
> discussing enhancing the code that is in the wrong place, which of
> course brings objections.
>
> I think we would be best served by stopping inheritance in its tracks
> and killing it off. It keeps getting in the way. What we need is real
> partitioning. Other uses are pretty obscure and we should re-examine
> things.
I actually think that inheritance is a pretty good foundation for real
partitioning. If we were to get rid of it, we'd likely end up needing
to add most of the same functionality back when we tried to do some
kind of real partitioning later, and that doesn't sound fun. I don't
see any reason why some kind of partitioning syntax couldn't be added
that leverages the existing inheritance mechanism but stores
additional metadata allowing for better optimization.
Well... I'm lying, a little bit. If our chosen implementation of
"real partitioning" involved some kind of partition objects that could
be created and dropped but never directly accessed via DML commands,
then we might not need anything that looks like the current planner
support for partitioned tables. But I think that would be a
surprising choice for this community. IMV, the problem with the
planner and inheritance isn't that there's too much cruft in there
already, but that there are still key optimizations that are missing.
Still, I'd rather try to fix that than start over.
> In the absence of that, releasing this updateable-security views
> without suppport for inheritance is a good move. It gives us most of
> what we want now and continuing to have some form of restriction is
> better than having a much greater restriction of it not working at
> all.
-1. Inheritance may be a crappy substitute for real partitioning, but
there are plenty of people using it that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company