From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Jeff Boes <jboes(at)nexcerpt(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Table partitioning for maximum speed? |
Date: | 2003-10-10 21:07:51 |
Message-ID: | 3F871FA7.6000306@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Boes wrote:
> Obviously, this is conceptually similar to what the index on the "md5"
> column is supposed to do for us. However, partitioning moves just a
> little of the processing load off the database server and onto the
> machine running the application. That's important, because we can afford
> more application machines as load increases, but we can't as easily
> upgrade the database server.
>
> Will a query against a table of 0.5 million rows beat a query against a
> table of 7 million rows by a margin that makes it worth the hassle of
> supporting 15 "extra" tables?
>
I don't think 16 tables on the same server will help, but if you already
have your app tier physically separate from the database tier, you could
partition your data to more than one database server based on the first
byte of the md5 column. I designed and built something similar a few
years ago. We never got to the point where we really needed that kind of
scalability, but it worked pretty well in (limited) testing.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Nigel J. Andrews | 2003-10-10 21:08:12 | Redhat RPMs (Was: Debian experimental packages ofPostgreSQL 7.4beta4) |
Previous Message | David Busby | 2003-10-10 21:04:51 | Index/Foreign Key Question |