-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/08/07 19:58, novnov wrote:
> You're right, that's not how I understood your partitioning question. I'd not
> be eager to implement that kind of split in the db, though I can see that
> it's an example of how to spread the load around.
>
> But basically, it seems that the answer to one of my questions is that there
> is currently no way with postgres to spread a single database over multiple
> servers, ala a loadbalanced apache cluster, where requests are forwarded to
> different boxes.
>
> It's not going to be an issue for me soon, maybe ever, I just wanted to see
> what the score is.
Scott is correct both in (a) that the money otherwise spent on RAC
can buy a big heap of extra oomph, and (b) "middleware partitioning"
method of scaling systems works very well.
Any way you go, though, requires proper design and coding from the
very beginning.
And it never hurts to think outside the box: sometimes you can get
the results you want by doing something that seems crazy. For
example, we had a couple of tables that were specifically designed
for OLTP. A specific weekly report that joined the 2 tables just
would *never* finish. Instead of fighting to create some hairy-
looking SQL-statement-from-Hell, I create WHERE-less views on the
two tables with only the columns that were needed. Now we have a
job that unloads the views, truncates then loads them into a
*separate* database (so that backups & CREATE INDEX don't clash),
indexes them perfectly for this query, and then runs the query
against this separate database.
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG42yaS9HxQb37XmcRAg+VAJ48E7pERfJ2MpRj2j9N4u1Wh01wJQCfUwnN
h1pHoRtnUOLrJkWOtg0Fs4A=
=7meG
-----END PGP SIGNATURE-----
