Subject: Re: On Scalability
From: "Joshua D. Drake" <jd@commandprompt.com>
Reply-To: jd@commandprompt.com
To: Vincenzo Romano <vincenzo.romano@notorand.it>
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <AANLkTi=6=WRpND-MXv92D-+iC9AnYDwLsbbXMXj4uNky@mail.gmail.com>
References: <AANLkTi=6=WRpND-MXv92D-+iC9AnYDwLsbbXMXj4uNky@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Command Prompt, Inc.
Date: Thu, 29 Jul 2010 10:12:06 -0700
Message-ID: <1280423526.8613.36.camel@jd-desktop.unknown.charter.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2010-07-29 at 19:08 +0200, Vincenzo Romano wrote:
> Hi all.
> I'm wondering about PGSQL scalability.
> In particular I have two main topics in my mind:
> 
> 1. What'd be the behavior of the query planner in the case I have
> a single huge table with hundreds or thousands of partial indexes
> (just differing by the WHERE clause).
> This is an idea of mine to make index-partitioning instead of
> table-partitioning.

Well the planner is not going to care about the partial indexes that
don't match the where clause but what you are suggesting is going to
make writes and maintenance extremely expensive. It will also increase
planning time as the optimizer at a minimum has to discard the use of
those indexes.

> 
> 2. What'd be the behavior of the query planner in the case I have
> hundreds or thousands of child tables, possibly in a multilevel hierarchy
> (let's say, partitioning by year, month and company).

Again, test it. Generally speaking the number of child tables directly
correlates to planning time. Most experience that 60-100 tables is
really the highest you can go.

It all depends on actual implementation and business requirements
however.

Sincerely,

Joshua D. Drake


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