Re: seq scan cache vs. index cache smackdown - Mailing list pgsql-performance

From Magnus Hagander
Subject Re: seq scan cache vs. index cache smackdown
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE47690D@algol.sollentuna.se
Whole thread Raw
In response to seq scan cache vs. index cache smackdown  (Mark Aufflick <mark@pumptheory.com>)
List pgsql-performance
>> 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 they
>> added it, though.
>>
>> (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?

Yes, they certainly seem very similar. The win32 functions are
explicitly designed for async I/O (they were after all created
specifically for SQL Server), so they put harder requirements on the
parameters. Specifically, it writes complete system pages only, and each
pointer has to point to only one page.
In a file opened without buffering it will also write all buffers out
and then wait for I/O completion from the device instead of one for
each. Not sure what the writev/readv ones do (not clear from my linux
man page).


Now wether this is something we could make use of - I'll leave that up
to those who know the buffer manager a lot better than I do.

//Magnus

pgsql-performance by date:

Previous
From: amrit@health2.moph.go.th
Date:
Subject: Problem with 7.4.5 and webmin 1.8 in grant function
Next
From: Tom Lane
Date:
Subject: Re: bad performances using hashjoin