Hi, Luke, Luke Lonergan wrote: > Since PG's heap scan is single threaded, the seek rate is equivalent to a > single disk (even though RAID arrays may have many spindles), the typical > random seek rates are around 100-200 seeks per second from within the > backend. That means that as sequential scan performance increases, such as > happens when using large RAID arrays, the random_page_cost will range from > 50 to 300 linearly as the size of the RAID array increases. Do you think that adding some posix_fadvise() calls to the backend to pre-fetch some blocks into the OS cache asynchroneously could improve that situation? I could imagine that e. G. index bitmap scans could profit in the heap fetching stage by fadvise()ing the next few blocks. Maybe asynchroneous I/O could be used for the same benefit, but posix_fadvise is less() intrusive, and can easily be #define'd out on platforms that don't support it. Combine this with the Linux Kernel I/O Scheduler patches (readahead improvements) that were discussed here in summer... Regards, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org
