posix advises ...

hello everybody,

recently we had a bit of a nightmare with some kernels and concurrent 
seq scans.
the thing we encountered was the following: a single "SELECT COUNT(*) 
FROM table" on a big table (50 gb) gave us constant 350 mb / sec I/O. as 
soon as a second scan dropped in speed dropped to 2 mb / sec. first i 
thought that some random I/O dropped in but synchronous scans worked 
fine. we found out that there is some madness in some linux kernel / 
controller combinations causing this issue.
it did some tests on my local boxes which was clearly not affected by 
this problem and I have seen a single SATA disks dropping from 65 mb / 
sec to around 45. this is not good.
i found a patch by grep stark implementing posix_fadvise for bitmap 
scans. i quickly hacked in suggestions to issue the same advises when a 
seq scan is done.
the impact was surprisingly high. single scans went up from 65 mb / sec 
to something around 70. concurrent scans are basically at steady, high 
speed - no dropping I/O speed anymore until something like 16 scans or so.
even the broken controller when up from "350mb -> 2mb" to "350 -> 50mb". 
by replacing the kernel and the driver we see steady behavior here as 
well now.

maybe it is worth to discuss posix_fadvise.
we hacked up a simple patch based on greg's work which nicely fixed the 
problem for us (brute force).
we also made some simple autoconf hack to check for broken posix_fadvise.
maybe people want to test if they see similar performance differences.
if a patch like that is likely to be accepted we would hack up some more 
clean implementation.

    many thanks,

       hans

-- 
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com