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
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? |