Re: Adding support for Default partition in partitioning

On Wed, Apr 5, 2017 at 2:51 PM, Keith Fiske <keith(at)omniti(dot)com> wrote:

>
>
> Only issue I see with this, and I'm not sure if it is an issue, is what
> happens to that default constraint clause when 1000s of partitions start
> getting added? From what I gather the default's constraint is built based
> off the cumulative opposite of all other child constraints. I don't
> understand the code well enough to see what it's actually doing, but if
> there are no gaps, is the method used smart enough to aggregate all the
> child constraints to make a simpler constraint that is simply outside the
> current min/max boundaries? If so, for serial/time range partitioning this
> should typically work out fine since there are rarely gaps. This actually
> seems more of an issue for list partitioning where each child is a distinct
> value or range of values that are completely arbitrary. Won't that check
> and re-evaluation of the default's constraint just get worse and worse as
> more children are added? Is there really even a need for the default to
> have an opposite constraint like this? Not sure on how the planner works
> with partitioning now, but wouldn't it be better to first check all
> non-default children for a match the same as it does now without a default
> and, failing that, then route to the default if one is declared? The
> default should accept any data then so I don't see the need for the
> constraint unless it's required for the current implementation. If that's
> the case, could that be changed?
>
> Keith
>

Actually, thinking on this more, I realized this does again come back to
the lack of a global index. Without the constraint, data could be put
directly into the default that could technically conflict with the
partition scheme elsewhere. Perhaps, instead of the constraint, inserts
directly to the default could be prevented on the user level. Writing to
valid children directly certainly has its place, but been thinking about
it, and I can't see any reason why one would ever want to write directly to
the default. It's use case seems to be around being a sort of temporary
storage until that data can be moved to a valid location. Would still need
to allow removal of data, though.

Not sure if that's even a workable solution. Just trying to think of ways
around the current limitations and still allow this feature.