For scaling you should consider slony. Either hangout on #slony on
Freenode.net or ask on the mailing list if you have questions.
For some reason I had thought slony was really immature, but it
actually looks really usable.
Intel chips => define more. There are Intel boxes known to have issues
under specific load scenarios with PostgreSQL (again specific
versions). To make it funnier, these are really really hard to track
down ;)
I can't access the Intel machine right now, but it's the current
fastest Intel dual-core. I'll figure it out tomorrow.
Cluster. One box that applies changes, and multiple boxes that read
the data.
If you cannot afford multiple boxes from the start, design your
application still to work with two connections: one connection to a
user with read/write permissions, and one connecting to a user having
only select permissions => this way you can later easily add a
loadbalancer to the mix, and use multiple postgres boxes for reading
stuff.
I think I'll see what I can do for that. Is there an aggregation-type
of clustering for Postgres? I'm thinking of something where database
information is divided between machines, rather than shared among them
as in Slony. Sort of like the difference between RAID0 and RAID1.
Since my application is constantly adding to the database (far more is
written than is ever read), it would be nice to have a multiple-write,
single reader solution, if such a thing exists.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
