Re: Anyone working on better transaction locking?
От | Tom Lane |
---|---|
Тема | Re: Anyone working on better transaction locking? |
Дата | |
Msg-id | 8236.1049906884@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Anyone working on better transaction locking? ("Ron Peacetree" <rjpeace@earthlink.net>) |
Ответы |
Re: Anyone working on better transaction locking?
|
Список | pgsql-hackers |
"Ron Peacetree" <rjpeace@earthlink.net> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> wrote in message > news:4096.1049860699@sss.pgh.pa.us... >> Ron, the tests that I've seen offer no support for that thesis. > What tests? I've seen no tests doing head-to-head, > feature-for-feature comparisons (particularly for low level features > like locking) of PostgreSQL vs the "biggies": DB2, Oracle, and SQL > Server. What data I have been able to find is application level, and > certainly not head-to-head. Who said anything about feature-for-feature comparisons? You made an (unsupported) assertion about performance, which has little to do with feature checklists. The reason I don't believe there's any fundamental MVCC problem is that no such problem showed up in the head-to-head performance tests that Great Bridge did about two years ago. GB is now defunct, and I have not heard of anyone else willing to stick their neck out far enough to publish comparative benchmarks against Oracle. But I still trust the results they got. I have helped various people privately with Oracle-to-PG migration performance problems, and so far the issues have never been MVCC or transaction issues at all. What I've seen is mostly planner shortcomings, such as failure to optimize "foo IN (sub-SELECT)" decently. Some of these things are already addressed in development sources for 7.4. >> Postgres certainly has plenty of performance issues, but I have no >> reason to believe that the fundamental MVCC mechanism is one of >> them. > Where in your opinion are they then? How bad are they in comparison > to MySQL or any of the "Big Three"? See the TODO list for some of the known problems. As for "how bad are they", that depends completely on the particular application and queries you are looking at ... regards, tom lane
В списке pgsql-hackers по дате отправления: