Skip site navigation (1) Skip section navigation (2)

Re: seq scan cache vs. index cache smackdown

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Magnus Hagander" <mha(at)sollentuna(dot)net>,<pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: seq scan cache vs. index cache smackdown
Date: 2005-02-21 14:03:20
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A762F@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-performance
> 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
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?

readv and writev are in the single unix spec...and yes they are
basically just like the win32 versions except that that are synchronous
(and therefore better, IMO).

On some systems they might just be implemented as a loop inside the
library, or even as a macro.

http://www.opengroup.org/onlinepubs/007908799/xsh/sysuio.h.html

On operating systems that optimize vectored read operations, it's pretty
reasonable to assume good or even great performance gains, in addition
to (or instead of) recent changes to xlog.c to group writes together for
a file...it just takes things one stop further.

Is there a reason why readv/writev have not been considered in the past?

Merlin

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2005-02-21 16:27:29
Subject: Re: seq scan cache vs. index cache smackdown
Previous:From: David BrownDate: 2005-02-21 14:03:03
Subject: Re: bad performances using hashjoin

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group