> Any chance you could put back the code in explain.c which showed
> whether posix_fadvise is actually getting used? Another thing I did
> when testing was attaching with strace to see if posix_fadvise (the
> syscall on linux was actually fadvise64 iirc) is actually getting
I tried changing this:
returnCode = posix_fadvise(VfdCache[file].fd, offset, amount,
returnCode = 0;
When I did that, it when back from 50 s to 33 s, which I think means
that posix_fadvise is getting called and that that is what is making
> And is this on a system with multiple spindles? How many?
Latitude D830 laptop. Single disk. Fedora 9. kernel-184.108.40.206-73.fc9.x86_64.
> And how much of the data is in shared buffers or in filesystem cache?
> Is this consistent for repeated queries? Is it only when you're
> repeating a query for dates that you've already selected?
I stopped the cluster, dropped the page cache, and restarted the
cluster just before testing. Repeated tests are fast due to caching
effects. shared_buffers is 240MB. System has 2GB RAM, steady state
is about 1GB of page cache.
> And how fast is it with effective_io_concurrency set to 1,2,3,5,6,7,8,...?
I do not currently have this information. :-)
I will try to run some more tests over the weekend, but I'm too tired
now and am starting to make mistakes.
> Do you see the same effect if you use a self-contained test case
> instead of the TPC-H data so I can try it?
Not sure exactly what you have in mind here. If you send a script or
something to reproduce I will try it.
In response to
pgsql-hackers by date
|Next:||From: Gregory Stark||Date: 2009-01-03 04:15:10|
|Subject: Re: posix_fadvise v22|
|Previous:||From: Joe Conway||Date: 2009-01-03 03:55:37|
|Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module|