On Wed, 2005-03-09 at 17:29, Greg Stark wrote:
> Scott Marlowe <smarlowe@g2switchworks.com> writes:
> > But what I'm really saying is that between good home grown partitioning
> > and fast hardware, the need for the pg devel team to implement
> > partitioning is pretty low.
>
> Ah. I thought you were saying that the fast hardware made partitioning in any
> form unnecessary. Not merely that it made home brew partitioning an acceptable
> solution.
>
> But that's a bit of a silly proviso though isn't it? I mean you could do
> anything with enough plpgsql code and fast enough hardware. The real question
> is where is the best place for this to be implemented.
Well, this is PostgreSQL, an extensible database, so the answer, to me,
is to implement it with a simple set of UDFs in userland as a proof of
concept. much like the materialized views recently discussed here.
After that, if someone thinks the basic concept is sound, it should get
migrated into the backend.
> Issuing a single atomic command sure makes me feel much better about something
> than trying to set up a half dozen triggers/rules on a view and hoping I get
> it all set up right. Especially when you think that I'll probably have to do
> this for several tables at the same time.
Sure, I'd love that too. But I think it's a bit too far ahead of the
game right now.
> Actually I have a strong feeling what really _ought_ to happen here is that
> the inherited tables support in postgres, which never really worked anyways,
> should be deprecated and eventually removed. All that infrastructure should be
> repurposed into partitioned tables. That seems like it would be a nice fit.
I would imagine that both might be saved by the same task. i.e. if
indexes and triggers could span across multiple tables etc... then
partitioned tables would be a pretty simple view creation.