* ktm@rice.edu (ktm@rice.edu) wrote:
> On Wed, Dec 03, 2014 at 10:00:26AM -0300, Alvaro Herrera wrote:
> > In my design I initially had overflow partitions too, because I
> > inherited the idea from Itagaki Takahiro's patch. Eventually I realized
> > that it's a useless concept, because you can always have leftmost and
> > rightmost partitions, which are just regular partitions (except they
> > don't have a "low key", resp. "high key"). If you don't define
> > unbounded partitions at either side, it's fine, you just raise an error
> > whenever the user tries to insert a value for which there is no
> > partition.
>
> Maybe I am not clear on the concept of an overflow partition, but I
> thought that it functioned to catch any record that did not fit the
> partitioning scheme. You end of range with out a "low key" or "high
> key" would only catch problems in those areas. If you partitioned on
> work days of the week, you should not have anything on Saturday/Sunday.
> How would that work? You would want to catch anything that was not a
> weekday in the overflow.
Yeah, I'm not a big fan of just dropping data on the floor either.
That's the perview of CHECK constraints and shouldn't be a factor of the
partitioning system, imv.
There is a flip side to this though, which is that users who have those
CHECK constraints probably don't want to be bothered by having to have
an overflow partition, which leads into the question of, if we have them
as a supported capability, what would the default be? My gut feeling is
that the default should be 'no overflow', in which case I'm not sure
it's useful as it won't be there for these cases where strange data
shows up unexpectedly and the system wants to put it somewhere.
Supporting overflow partitions would also mean supporting the ability to
move data out of those partitions and into 'real' partitions which the
user creates to deal with the odd/new data. That doesn't strike me as
being too much fun for us to have to figure out, though if we do, we
might be able to do a better job (with less blocking happening, etc)
than the user could.
Lastly, my inclination is that it's a capability which could be added
later if there is demand for it, so perhaps the best answer is to not
include it now (feature creep and all that).
Thanks,
Stephen
