Re: Transparent table partitioning in future version of PG?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: henk de wit <henk53602(at)hotmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Transparent table partitioning in future version of PG?
Date: 2009-05-01 15:27:04
Message-ID: 603c8f070905010827n1feec826w2cfcbc90d3be038b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, May 1, 2009 at 10:32 AM, henk de wit <henk53602(at)hotmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message James Nelson 2009-05-01 15:42:46 Re: bad plan and LIMIT
Previous Message James Nelson 2009-05-01 15:07:50 Re: bad plan and LIMIT