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

From Craig Ringer
Subject Re: Transparent table partitioning in future version of PG?
Date
Msg-id 4A04DB92.1060405@postnewspapers.com.au
Whole thread Raw
In response to Re: Transparent table partitioning in future version of PG?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
Robert Haas wrote:

> Well, even if the table is not partitioned at all, I don't see that it
> should preclude parallel query access.  If I've got a 1 GB table that
> needs to be sequentially scanned for rows meeting some restriction
> clause, and I have two CPUs and plenty of I/O bandwidth, ISTM it
> should be possible to have them each scan half of the table and
> combine the results.  Now, this is not easy and there are probably
> substantial planner and executor changes required to make it work, but
> I don't know that it would be particularly easier if I had two 500 MB
> partitions instead of a single 1 GB table.

The point of partitioning in this scenario is primarily that you can put
the different partitions in different tablespaces, most likely on
independent disk devices. You therefore get more I/O bandwidth.

--
Craig Ringer

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL with PostGIS on embedded hardware
Next
From: Tom Lane
Date:
Subject: Re: Bad Plan for Questionnaire-Type Query