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 603c8f070905081353m528b0f6dkf1e9432a98639efd@mail.gmail.com
Whole thread Raw
In response to Re: Transparent table partitioning in future version of PG?  (david@lang.hm)
Responses Re: Transparent table partitioning in future version of PG?
List 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

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Transparent table partitioning in future version of PG?
Next
From: Tom Lane
Date:
Subject: Re: Transparent table partitioning in future version of PG?