Re: seq scan cache vs. index cache smackdown

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: seq scan cache vs. index cache smackdown
Date: 2005-02-20 18:25:33
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE47690D@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-02-20 18:46:10 Re: bad performances using hashjoin
Previous Message amrit 2005-02-20 15:49:30 Problem with 7.4.5 and webmin 1.8 in grant function