On 6/22/06, Hannu Krosing <[EMAIL PROTECTED]> wrote:
I guess that MySQL on its original storage does that, but they allow only one concurrent update per table and no transactions.
More like practically every commercial database. As ~97% of transactions commit (yes, some can argue that number), most commercial systems prefer optimistic storage managers; whereas PostgreSQL opts for the ~3% of pessimistic cases. Let's see, if I had a 97% chance of winning the lottery... I'd probably play a lot more than if I only had a 3% chance.
One way to describe what "commercial databases" do to keep constant update rates is saying that they do either vacuuming as part of update, or they just use locks anf force some transactions to wait or fail/retry.
Not exactly... there are several ways to handle UNDO without locking. Certainly the other systems have to perform background cleanup, but I'd hardly compare that to vacuuming.
Depending on exact details and optimisations done, this can be either slower or faster than postgresql's way, but they still need to do something to get transactional visibility rules implemented.
No argument there... but I have yet to find proof that straight-out-of-CVS PostgreSQL (including tuning) is faster than any commercial system on almost any large workload. Without a doubt, our MVCC is in most cases, much nicer than other OSS databases. However, it hasn't yet proven itself to be better than the concepts employed by the database vendors with billions of dollars. The reasoning behind PostgreSQL's storage and MVCC architecture made sense for its design, but this had nothing to do with creating a super-highly-concurrent database.
Running the server at 100% lead is not anything you want to do on production server. There will be things you need to do anyway and you need some headroom for that.
No argument there. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | [EMAIL PROTECTED] Iselin, New Jersey 08830 | http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
