* k...@rice.edu (k...@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
signature.asc
Description: Digital signature