>>
>>
> I would think that you could probably get 80% of the performance with
> ordinary threads and ordinary blocking IO, and without the great
> increase in complexity required to implement asynchronous IO. If
> someone then wants to go after a possible 25% performance gain, they
> could submit a working set of modifications, or wait a few months for
> the hardware to catch up.
>
This argument doesn't work for several reasons:
1. Hardware generally does not catch up because:
A. Users demand increases and thus the load on the hardware
increases.
B. Users don't purchase new hardware every couple of months.
2. If we were talking about a 5% performance gain that "might" be
acceptable but
the 20% gain you are talking about is huge. Think about it:
I have several customers right now that push over 250,000 (some as
high as 750,000)
transactions an hour. They are pushing the hardware hard as it is,
especially with the
limitations of Vacuum. If they were to move to the Win32 version (it
doesn't matter why),
they would loose 50,000 transactions an hour based on your argument.
That is completely illegitamate and would make PostgreSQL look like
a toy on Windows.
We already have PostgreSQL as a toy on Windows, it uses Cygwin.
> - Marsh
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org