Re: posix_fadvise v22

> 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