From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Chris Travers <chris(at)travelamericas(dot)com> |
Cc: | ahester(at)galacticltd(dot)com, pgsql-advocacy(at)postgresql(dot)org |
Subject: | Re: Is Postgres comparable to MSSQL |
Date: | 2005-10-18 20:27:26 |
Message-ID: | 43555AAE.8020209@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Chris Travers wrote:
> On the advantages, MS SQL has at least a commercial attempt at
> multimaster replication (both async and sync). I suspect you can
> architect similar solutions with PGPool and/or Slony-I but these may be
> more complex to set up initially than MS SQL...
I haven't maintained a MSSQL replication personally, but a co-worker did
for some years and apparently a simple async master-slave replication
needed quite some effort to implement, needing lengthy scripts since the
Enterprise Manager didn't work for that situation); in addition it broke
down from time to time, requiring a fresh initial setup. I'm quite sure
that Slony-I performs at least as good (frankly, I believe the
architecture is much better).
> Also it is mostly self-tuning on Windows.
Agreed; pgsql can never be as good in this discipline, too many platforms.
> For example, I am not really happy with the fact that what MS
> SQL calls "triggers" are really our rule system by another name and that
> they have no real trigger system of the sort that we, DB2, or Oracle
> have. Yes, it is sufficient for 80% of your cases, but it leaves some
> reasonable gaps in functionality.
Um, MSSQL triggers == pgsql rules? All TSQL language structs may be used
(e.g. IF); pgsql rules lack plpgsql or similar for this, which allows
simple rules only.
In fact, I like MSSQL triggers when it comes to volume oriented work. I
once programmed a system where a single query might affect thousands of
rows, which in turn triggers changes in another table, also with
triggers... Works fine with decent performance.
With statement triggers, this effectively leads to three statements on
larger rowsets, which can be optimized by the planner, while doing it
with row level triggers each row will create an individual query on
small rowsets. BTW here's a current weakness of pgsql: statement
triggers still don't allow access to affected rowsets using OLD and NEW.
>
> I used to work at Microsoft's Product Support Services. I was not
> impressed by MS SQL after hearing dealing with many support calls.
When I started adapting a win32 app (fairly portable developed on MSSQL)
to PostgreSQL, I got about 6 issues that had to be solved. 5 issues were
pgsql related, all of them solved in less than 24 hours. The 6th was a
MS software related problem (OLEDB driver), handled as paid case. After
6 weeks, the case was closed with "yes, this is a MS bug, we won't fix
it because it appears irrelevant to us".
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Youngblood | 2005-10-18 20:36:08 | Re: [GENERAL] Oracle buys Innobase |
Previous Message | Chris Travers | 2005-10-18 20:19:53 | Re: [pgsql-advocacy] Oracle buys Innobase |