Re: High traffic websites...
От | Jeff |
---|---|
Тема | Re: High traffic websites... |
Дата | |
Msg-id | ce3adb999f4c422e300b7de9dcd61297@torgo.978.org обсуждение исходный текст |
Ответ на | Re: High traffic websites... (Sam Hahn <SamHahn@StoneSpring.org>) |
Список | pgsql-advocacy |
On Apr 1, 2005, at 10:32 AM, Sam Hahn wrote: > Jeff - Thanks for your mention below. I'm curious how PG was selected > in the first place, and whether management was conscious of it at the > time... How long does it normally take for you to do the hot-swap (if > ever)? Have you explicitly decided what PG-specific features / > extensions you will adopt? or not? Were there Informix-specific > features that you had taken advantage of? Thx - Sam > We fear informix here. We're stuck on an ancient version that is fairly broken and there is nothing we can do about it. So we had some products come up that needed some db support but we didn't want to add anything to Informix so I advocated PG because (mostly) of stored procedures and I had been playing with it recently. I did get some resistance (They wanted me to use flat files) but I won. You know what? It works like a champ. It was the DB people would forget about because it would keep plugging away. The only big "failures" it has had were when the power supply blew. As for the hot swap, we've never actually had to do it, but it will just be a matter of changing pgpool's config to point to the spare and restarting it (and of course, the slony side of it). I think I forgot to mention we use pgpool - that thing is the bestestestestest thing ever (thanks Tatsuo!). I wish we had one for Oracle (We use Oracle on some other Lycos products) I use triggers & stored procs extensively in PG. Also I have some clever stuff using LISTEN/NOTIFY. One of the niftier tools I wrote takes a stored proc in PG and will generate glue code in either c or perl so you can call it natively. (The C one will actually build out the structs and perform the data mangling so you can call those stored procs like a regular function. That is the basis of the new arch for RB). The only thing we really used on Informix were stored procs. Every other nifty Informix feature we've tried has been broken - table partitioning didn't work (We ended up getting invalid results when we added an index - informix told us it was a bug and we're in trouble)... we hit the 21.7M pages of data/table "limit". That was painful. The error you get when you hit that limit is "No more extents" so you figure "ok, I'll redo the table with bigger extents" [12 hours later] "Hmm.. I got that error again. WTF?" [more googling] "ARRRG! 21.7M pages of data! Grumble". -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
В списке pgsql-advocacy по дате отправления: