Someone wrote: >>> >>> Should we consider only telling the kernel X pages ahead, meaning when >>> we are on page 10 we tell it about page 16?
The patch I posted specifically handles bitmap heap scans. It does in fact prefetch only a limited number of pages from the bitmap stream based on a guc, but it tries to be a bit clever about ramping up gradually. The real danger here, imho, is doing read-ahead for blocks the client never ends up reading. By ramping up the read-ahead gradually as the client reads records we protect against that. > Heikki Linnakangas wrote: >> >> Yes. You don't want to fire off thousands of posix_fadvise calls >> upfront. That'll just flood the kernel, and it will most likely ignore >> any advise after the first few hundred or so. I'm not sure what the >> appropriate amount of read ahead would be, though. Probably depends a >> lot on the OS and hardware, and needs to be a adjustable. "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > And if you read-ahead too far the pages might get pushed out of the > kernel cache before you ask to read them. While these concerns aren't entirely baseless the actual experiments seem to show the point of diminishing returns is pretty far out there. Look at the graphs below, keeping in mind that the X axis is the number of blocks prefetched. http://archives.postgresql.org/pgsql-hackers/2007-12/msg00088.php The pink case is analogous to a bitmap index scan where the blocks are read in order. In that case the point of diminishing returns is reached around 64 pages. But performance doesn't actually dip until around 512 pages. And even prefetching 8,192 blocks the negative impact on performance is still much less severe than using a smaller-than-optimal prefetch size. This is on a piddly little 3-way raid. On a larger raid you would want even larger prefetch sizes. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
