Re: Issue for partitioning with extra check constriants - Mailing list pgsql-performance

From Joshua D. Drake
Subject Re: Issue for partitioning with extra check constriants
Date
Msg-id 1286217866.28987.14.camel@jd-desktop.unknown.charter.com
Whole thread Raw
In response to Re: Issue for partitioning with extra check constriants  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
On Mon, 2010-10-04 at 11:34 -0700, Josh Berkus wrote:
> > And your point is?  The design center for the current setup is maybe 5
> > or 10 partitions.  We didn't intend it to be used for more partitions
> > than you might have spindles to spread the data across.
>
> Where did that come from?

Yeah that is a bit odd. I don't recall any discussion in regards to such
a weird limitation.

>  It certainly wasn't anywhere when the feature
> was introduced.  Simon intended for this version of partitioning to
> scale to 100-200 partitions (and it does, provided that you dump all
> other table constraints), and partitioning has nothing to do with
> spindles.  I think you're getting it mixed up with tablespaces.

Great! that would be an excellent addition.


>
> The main reason for partitioning is ease of maintenance (VACUUM,
> dropping partitions, etc.) not any kind of I/O optimization.

Well that is certainly "a" main reason but it is not "the" main reason.
We have lots of customers using it to manage very large amounts of data
using the constraint exclusion features (and gaining from the smaller
index sizes).


Jd

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Issue for partitioning with extra check constriants
Next
From: Josh Berkus
Date:
Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance