Re: Transparent table partitioning in future version of PG? - Mailing list pgsql-performance

From Robert Haas
Subject Re: Transparent table partitioning in future version of PG?
Date
Msg-id 603c8f070905010827n1feec826w2cfcbc90d3be038b@mail.gmail.com
Whole thread Raw
In response to Transparent table partitioning in future version of PG?  (henk de wit <henk53602@hotmail.com>)
Responses Re: Transparent table partitioning in future version of PG?
List pgsql-performance
On Fri, May 1, 2009 at 10:32 AM, henk de wit <henk53602@hotmail.com> wrote:
> I was looking at the support that PostgreSQL offers for table partitioning
> at http://www.postgresql.org/docs/8.4/static/ddl-partitioning.html. The
> concept looks promising, but its maybe fair to say that PG itself doesn't
> really supports partitioning natively, but one can simulate it using some of
> the existing PG features (namely inheritance, triggers, rules and constraint
> exclusion). This simulating does seem to work, but there are some
> disadvantages and caveats.
> A major disadvantage is obviously that you need to set up and maintain the
> whole structure yourself (which is somewhat dangerous, or at least involves
> a lot of maintenance overhead). Next to that, it seemingly becomes hard to
> do simple queries likes 'select * from foo where bar> 1000 and bar < 5000',
> in case the answer to this query spans multiple partitions. constraint
> exclusion works to some degree, but the document I referred to above tells
> me I can no longer use prepared statements then.
> I wonder if there are any plans to incorporate 'native' or 'transparent'
> partitioning in some future version of PG? With this I mean that I would
> basically be able to say something like (pseudo): "alter table foo partition
> on bar range 100", and PG would then simply start doing internally what we
> now have to do manually.
> Is something like this on the radar or is it just wishful thinking of me?
> Kind regards

This has been discussed on this list multiple times previously; search
the archives.

The problem has been finding someone who has both the time and the
ability to do the work.

...Robert

pgsql-performance by date:

Previous
From: James Nelson
Date:
Subject: Re: bad plan and LIMIT
Next
From: James Nelson
Date:
Subject: Re: bad plan and LIMIT