(For those not knowing - it's ReadFile/WriteFile where you pass an array
of this many bytes to this address as parameters)
Isn't that like the BSD writev()/readv() that Linux supports also? Is
that something we should be using on Unix if it is supported by the OS?
Nope, readv()/writev()
Magnus Hagander wrote:
I don't think that's correct either. Scatter/Gather I/O is used to
SQL
Server can issue reads for several blocks from disks into it's own
buffer cache with a single syscall even if these buffers are not
sequential. It did make significant performance improvements
Merlin Moncure [EMAIL PROTECTED] writes:
Is there a reason why readv/writev have not been considered in the past?
Lack of portability, and lack of obvious usefulness that would justify
dealing with the lack of portability.
I don't think there's any value in trying to write ordinary buffers this
Merlin Moncure wrote:
readv and writev are in the single unix spec...and yes ...
On some systems they might just be implemented as a loop inside the
library, or even as a macro.
You sure?
Requirements like this:
http://www.opengroup.org/onlinepubs/007908799/xsh/write.html
Write requests of
Magnus Hagander wrote:
I don't think that's correct either. Scatter/Gather I/O is used to SQL
Server can issue reads for several blocks from disks into it's own
buffer cache with a single syscall even if these buffers are not
sequential. It did make significant performance improvements when
It seems inevitable that Postgres will eventually eliminate that
redundant
layer of buffering. Since mmap is not workable, that means using
O_DIRECT
to
read table and index data.
What about going the other way and simply letting the o/s do all the
caching? How bad (or good) would the
My concern is that this kind of testing has very little relevance to the
real world of multiuser processing where contention for the cache becomes an
issue. It may be that, at least in the current situation, postgres is
giving too much weight to seq scans based on single user, straight
The world rejoiced as [EMAIL PROTECTED] (Mark Aufflick) wrote:
Hi All,
I have boiled my situation down to the following simple case:
(postgres version 7.3)
* Query 1 is doing a sequential scan over a table (courtesy of field
ILIKE 'foo%') and index joins to a few others
* Query 2 is doing
Hi Rod,
Any solution fixing buffers should probably not take into consideration
the method being performed (do you really want to skip caching a
sequential scan of a 2 tuple table because it didn't use an index) but
the volume of data involved as compared to the size of the
