Re: Transparent table partitioning in future version of PG?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: david(at)lang(dot)hm
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, henk de wit <henk53602(at)hotmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Transparent table partitioning in future version of PG?
Date: 2009-05-08 20:53:16
Message-ID: 603c8f070905081353m528b0f6dkf1e9432a98639efd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>> IOW, I don't think you should need to partition if all you want is
>> load balancing.  Partitioning should be for isolation, and load
>> balancing should happen when appropriate, whether there is
>> partitioning involved or not.
>
> actually, I will contridict myself slightly.
>
[...]
> however, trying to split the work on a single table runs into all sorts of
> 'interesting' issues with things needing to be shared between the multiple
> processes (they both need to use the same indexes, for example)

I disagree with this part of your email. It is already the case that
tables and indexes need to support concurrent access by multiple
Postgres processes. I don't see why that part of the problem would be
any more difficult for parallel query execution than it would be for
executing two different and unrelated queries on the same table.

> so I think that it is much easier for the database engine to efficiantly
> search two 500G tables instead of one 1T table.

And that leads me to the opposite conclusion on this point.

...Robert

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-05-08 21:03:30 Re: Transparent table partitioning in future version of PG?
Previous Message Scott Carey 2009-05-08 19:40:07 Re: Transparent table partitioning in future version of PG?