On Mon, Oct 13, 2014 at 04:38:39PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Aug 29, 2014 at 11:56:07AM -0400, Alvaro Herrera wrote:
> > > Prompted by a comment in the UPDATE/LIMIT thread, I saw Marko Tiikkaja
> > > reference Tom's post
> > > http://www.postgresql.org/message-id/1598.1399826841@sss.pgh.pa.us
> > > which mentions the possibility of a different partitioning
> > > implementation than what we have so far. As it turns out, I've been
> > > thinking about partitioning recently, so I thought I would share what
> > > I'm thinking so that others can poke holes. My intention is to try to
> > > implement this as soon as possible.
> >
> > I realize there hasn't been much progress on this thread, but I wanted
> > to chime in to say I think our current partitioning implementation is
> > too heavy administratively, error-prone, and performance-heavy.
>
> On the contrary, I think there was lots of progress; there's lots of
> useful feedback from the initial design proposal I posted. I am a bit
> sad to admit that I'm not working on it at the moment as I had
> originally planned, though, because other priorities slipped in and I am
> not able to work on this for a while. Therefore if someone else wants
> to work on this topic, be my guest -- otherwise I hope to get on it in a
> few months.
Oh, I just meant code progress --- I agree the discussion was fruitful.
> > I support a redesign of this feature. I think the current mixture of
> > inheritance, triggers/rules, and check constraints can be properly
> > characterized as a Frankenstein solution, where we paste together parts
> > until we get something that works --- our partitioning badly needs a
> > redesign.
>
> Agreed, and I don't think just hiding the stitches is good enough.
LOL, yeah. I do training on partitioning occasionally and the potential
for mistakes is huge.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
