Re: Anyone working on better transaction locking?

Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:

> But database is not webserver. It is not suppose to handle tons of concurrent
> requests. That is a fundamental difference.

And in one fell swoop you've dismissed the entire OLTP database industry.

Have you ever called a travel agent and had him or her look up a fare in the
airline database within seconds? Ever placed an order over the telephone?
Ever used a busy database-backed web site?

On database-backed web sites, probably the main application for databases
today, almost certainly the main application for free software databases,
every web page request translates into at least one, probably several database
queries.

All those database queries must complete within a limited time, measured in
milliseconds. When they complete another connection needs to be context
switched in and run again within milliseconds.

On a busy web site the database machine will have several processors and be
processing queries for several web pages simultaneously, but what really
matters is precisely the context switch time between one set of queries and
another.

The test I'm most interested in in the benchmarks effort is simply an index
lookup or update of a single record from a large table. How many thousands of
transactions per second is postgres going to be able to handle on the same
machine as mysql and oracle? How many hundreds of thousands of transactions
per second will they be able to handle on a 4 processor hyperthreaded machine
with a raid array striped across ten disks?

--
greg