On Thu, Dec 8, 2011 at 6:47 PM, Rodger Donaldson <rodg...@diaspora.gen.nz> wrote: > On Thu, 8 Dec 2011 16:34:49 -0800, Chris Travers <chris.trav...@gmail.com> > wrote: >> On Thu, Dec 8, 2011 at 4:09 PM, Rodger Donaldson >> <rodg...@diaspora.gen.nz> wrote: >>> On Thu, 08 Dec 2011 11:24:12 -0800, John R Pierce <pie...@hogranch.com> >>> wrote: >>>> On 12/08/11 11:16 AM, Joshua D. Drake wrote: >>>>>> >>>>>> um, I believe this is referring to Oracle RAC clustering, not HA >>>>>> active/standby. I seriously doubt Oracle is dropping RAC. >>>>> >>>>> I meant worrying about it for Pg. >>>> >>>> the odds of Postgres developing something as complex and intricate as >>>> RAC are probably between zilch and none. RAC was for many years >>>> completely unusable, and even now, its complicated, fragile, and >>> expensive. >>> >>> Happily, the complications and fragility are now utilised by Oracle to >>> help sell ExaData units, on the basis that if you give Oracle even more >>> money, they'll sell you a RAC that actually works! >> >> Looking at the general design of Postgres-XC compared to RAC, which >> workloads would the latter excel at as a matter of design that the >> former would not? > > Not having touched -XC I can only theorycraft, but if I've understood the > shared-nothing model correctly, I'd expect it to hammer RAC in high-write > workloads, based on my experience of contention in RAC servers - a common > condition is that since the SGA is (effectively) shared across the RAC > interconnect, you're effectively limiting your peak write performance to > the throughput and latency of your ethernet link (which is, I assume, why > the ExaData uses Infiniband). We've had to do things like set up seperate > connection pools which write to one node at a time (with failover, of > course) for high-INSERT tables to avoid the RAC becoming painfully slow.
I think you have to define "shared-nothing" in this context. Like a shared-storage architecture, this has two tiers, namely a tier that orchestrates queries and a storage tier for lack of a better word. In other words, XC is attempting to be like Teradata more than like RAC. In fact one of the key issues here is that Postgres-XC is supposed to be write-scalable. > > On the other hand I don't see anything that would suggest -XC will work as > seamlessly for failover as the RAC does. We went through a period where > our applications (and DBAs!) failed to notice kernel-panic induced reboots > of RAC members at least once every couple of weeks, with absolutely no > customer impact. Looking to me like it would be quite possible to set it up so that it would be seemless in the event of node reboots at least on the coordinator tier. On the storage tier, not sure the extent to which this would be possible but it might depend on Postgresql replication options and how well supported they are by XC. > > Anyway, my comment was more of a dig at the selling pitch for ExaData: I > have had it pitched with a straight face that I should want to buy one > because RAC is so hard to configure and maintain. In which case it's good that Pg isnt gunning for that market, right? > >> Granted Postgres-XC is still pre-1.0 (latest >> release iirc is 0.9.6) and it doesn't yet support everything it needs >> to, but it looks very promising in this area, and it is open source. > > It looks really interesting. Thanks for the pointer. YW :-) Chris Travers -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
