| Sigh. The usual downvotes because... why, you can pick holes in what I said, or some people's identity is so tied up with a piece of open-source software that they can't tolerate apparent criticism of it? Fact: the optimiser in an SQL engine is almost the quintessence of it. If you don't understand that then you don't understand that the potential cost of the declarative nature of SQL. Fact: SQL optimisers are complex. New fact: microsoft has pumped fantastic amounts of cash into MSSQL. Posgres just doesn't have those resources (and other resources, such as the late lamented Jim Gray). Other fact. Postgres CTEs were an optimisation barrier until PG11 or PG12 (https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-...). AFAIK MSSQL's CTEs have never been an optimisation barrier, and I've used them long enough to know. I'm also trying to understand the cost of MVCC, which PG uses but MSSQL now has as an option, to try and understand where that costs, because depending on the scenario, it will. PG does not have READ UNCOMMITTED. Fact: The guy I quoted had used postgres on large data a while back and said it wasn't as good as MSSQL. He had experience, which is the bottom line. I also acknowledged this may have changed recently. Other fact: I don't dislike postgres and recently have decided learn PG also, because, for very good reason, MSSQL has its problems (the ridiculous cost not being the only one). Fact: If you just downvote me without explaining why, neither of us can learn anything. |
Didn't downvote you but your first comment I found vacuous. "Possibly", "could pump", "I was informed...I've no experience of it".
Your second comment then asserts things which may very well be true, but would be more believable with some references.