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/