Adding -performance back; you should do a reply-all if you want to reply to list messages.
> From: Jeremy Haile [mailto:jhaile@fastmail.fm]
> > Can you point us at more info about this? I can't even find
> a website
> > for Ingres...
>
> Ingres is based off of the same original codebase that PostgreSQL was
> based upon (a long time ago) It is owned by Computer
> Associates and was
> open sourced last year. It supports clustering and replication, and
> I've seen an Ingres install set up as a cluster backed by a
> SAN before.
> I just haven't talked to anyone (at least unbiased) who has used this
> type of setup in production, and I'm not fully aware of the
> advantages/disadvantages of this type of setup with Ingres.
> Since this
> group seems pretty knowledgable about performance advantages
> (and we are
> currently running PostgreSQL), I wanted to see if there were any
> experiences or opinions.
>
> Here is a link to their website:
> http://opensource.ca.com/projects/ingres
>
>
> > Perhaps if you posted your performance requirements someone
> could help
> > point you to a solution that would meet them.
>
> This is honestly more of a curiousity question at the moment,
> so I don't
> have any specific numbers. We definitely have a requirement for
> failover in the case of a machine failure, so we at least need
> Master->Slave replication. However, I wanted to solicit
> information on
> clustering alternatives as well, since scalability will likely be a
> future problem for our database.
Ahh, ok... that's likely a much different requirement than true clustering.
What a lot of folks do right now is segregate their application into a read-only stream and the more interactive
read-writestreams, and then use Slony to replicate data to a number of machines for the read-only work. This way anyone
who'shitting the site read-only (and can handle some possible delay) will just hit one of the slave machines. People
whoare doing interactive work (updating data) will hit the master. Since most applications do far more reading than
theydo writing, this is a pretty good way to load-balance.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461