[continued from previous message]
PostgreSQL (MVCC) in a context of almost exclusively read-only
transactions? Note that if transactions are read-only, versions are not created.
First, we do not have Transactions for read-only operations, thus you do have an overhead that we don’t have. I would not suggest that that is equal to the “added” locking we have for read-only operations, because it is minuscule in comparison.
Second, whatever you do produce as a result set is false wrt SQL compliance, whereas ours is true. A brain-dead series of offline stale uncommitted (you have no real implementation of COMMIT) versions of rows is not comparable to a series of true
committed online rows at READ COMMITTED. Sure, a new version may not be *created*, but the version taken and used is false, just as when a version *IS* created.
Third, and most important, the problem is in your question. It is stated with a limited scope, that is yours, not mine. I do not justify Sybase over AsylumGres “in a context of almost exclusively read-only [operations]”.
I justify Sybase over AsylumGres for
- OLTP only;
- AND for mixed OLTP+OLAP,
- AND for OLAP only.
Because I prefer reality to materialised fantasy, in all contexts that can be related to the provision of an SQL platform, an SQL and ACID compliant architected server. Refer to the Architecture vs Non-Architecture performance links above.
Does this assessment satisfy you?
Yes, it is the best I have received from an academic. No fuss; no nonsense; no idiotic argumentation; no dishonest Straw Men (that which is due to indoctrination is excused); no splitting hairs. You are engaging your lineage back to 1492. You are
starting to heave (the harsh but non-issuing action that precedes vomiting) at Modernism. Progressively leaving the asylum, in the direction of science.
Cheers
Derek
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)