> 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
> called.
I tried changing this:
returnCode = posix_fadvise(VfdCache[file].fd, offset, amount,
POSIX_FADV_WILLNEED);
to this:
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
it slower.
> And is this on a system with multiple spindles? How many?
Latitude D830 laptop. Single disk. Fedora 9. kernel-2.6.27.9-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.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
