Re: Hash partitioning. - Mailing list pgsql-hackers

From ktm@rice.edu
Subject Re: Hash partitioning.
Date
Msg-id 20130626140113.GF11110@aart.rice.edu
Whole thread Raw
In response to Re: Hash partitioning.  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Hash partitioning.  ("Yuri Levinsky" <yuril@celltick.com>)
Re: Hash partitioning.  (Markus Wanner <markus@bluegap.ch>)
Re: Hash partitioning.  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Wed, Jun 26, 2013 at 03:47:43PM +0200, Markus Wanner wrote:
> On 06/25/2013 11:52 PM, Kevin Grittner wrote:
> > At least until we have parallel
> > query execution.  At *that* point this all changes.
> 
> Can you elaborate on that, please? I currently have a hard time
> imagining how partitions can help performance in that case, either. At
> least compared to modern RAID and read-ahead capabilities.
> 
> After all, RAID can be thought of as hash partitioning with a very weird
> hash function. Or maybe rather range partitioning on an internal key.
> 
> Put another way: ideally, the system should take care of optimally
> distributing data across its physical storage itself. If you need to do
> partitioning manually for performance reasons, that's actually a
> deficiency of it, not a feature.
> 
> I certainly agree that manageability may be a perfectly valid reason to
> partition your data. Maybe there even exist other good reasons. I don't
> think performance optimization is one. (It's more like giving the system
> a hint. And we all dislike hints, don't we? *ducks*)
> 
> Regards
> 
> Markus Wanner
> 

Hi Markus,

I think he is referring to the fact that with parallel query execution,
multiple partitions can be processed simultaneously instead of serially
as they are now with the resulting speed increase.

Regards,
Ken



pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: Re: Hash partitioning.
Next
From: Jamie Martin
Date:
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]