Re: [HACKERS] [SPAM?] Re: Asynchronous I/O Support
Hi, While we are at async i/o. I think direct i/o and concurrent i/o also deserve a look at. The archives suggest that Bruce had some misgivings about dio because of no kernel caching, but almost all databases seem to (carefully) use dio (Solaris, Linux, ?) and cio (AIX) extensively nowadays. Since these can be turned on a per file basis, perf testing them out should be simpler too. Regards, Nikhils On 10/25/06, Martijn van Oosterhoutwrote: On Tue, Oct 24, 2006 at 12:53:23PM -0700, Ron Mayer wrote:> Anyway, for those who want to see what they do in Linux, > http://www.gelato.unsw.edu.au/lxr/source/mm/fadvise.c> Pretty scary that Bruce said it could make older linuxes> dump core - there isn't a lot of code there. The bug was probably in the glibc interface to the kernel. Google foundthis:http://sourceware.org/ml/libc-hacker/2004-03/msg0.html i.e. posix_fadvise appears to have been broken on all 64-bitarchitechtures prior to March 2004 due to a silly linking error.And then things like this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313219Which suggest that prior to glibc 2.3.5, posix_fadvise crashed on 2.4kernels. That's a fairly recent version, so the bug would still befairly widespead. Have a nice day,--Martijn van Oosterhout http://svana.org/kleptog/> From each according to his ability. To each according to his ability to litigate. -BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFFPnYrIB7bNG8LQkwRAuAqAJ4uqx8y9LxUa9RcEDm7CPwZ2lkS2wCfYxjB2KzJ7iDYU21lumcZT6cHeLI==MzUY-END PGP SIGNATURE- -- All the world's a stage, and most of us are desperately unrehearsed.
Re: [HACKERS] [SPAM?] Re: Asynchronous I/O Support
On Tue, Oct 24, 2006 at 12:53:23PM -0700, Ron Mayer wrote: > Anyway, for those who want to see what they do in Linux, > http://www.gelato.unsw.edu.au/lxr/source/mm/fadvise.c > Pretty scary that Bruce said it could make older linuxes > dump core - there isn't a lot of code there. The bug was probably in the glibc interface to the kernel. Google found this: http://sourceware.org/ml/libc-hacker/2004-03/msg0.html i.e. posix_fadvise appears to have been broken on all 64-bit architechtures prior to March 2004 due to a silly linking error. And then things like this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313219 Which suggest that prior to glibc 2.3.5, posix_fadvise crashed on 2.4 kernels. That's a fairly recent version, so the bug would still be fairly widespead. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [SPAM?] Re: Asynchronous I/O Support
Zeugswetter Andreas ADI SD wrote: > POSIX_FADV_WILLNEED definitely sounds very interesting, but: > > I think this interface was intended to hint larger areas (megabytes). > But the "wishful" thinking was not to hint seq scans, but to advise > single 8k pages. Surely POSIX_FADV_SEQUENTIAL is the one intended to hint seq scans, and POSIX_FADV_RANDOM to hint random access. No? ISTM, _WILLNEED seems just right for small random-access blocks. Anyway, for those who want to see what they do in Linux, http://www.gelato.unsw.edu.au/lxr/source/mm/fadvise.c Pretty scary that Bruce said it could make older linuxes dump core - there isn't a lot of code there. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match