Heikki Linnakangas wrote: > > So it has nothing to do with table size. The fadvise calls need to be > > (and are) > > limited by what can be used in the near future, and not for the whole > > statement. > > Right, I was sloppy. Instead of table size, what matters is the amount > of data the scan needs to access. The point remains that if the data is > already in OS cache, the posix_fadvise calls are a waste of time, > regardless of how many pages ahead you advise.
I now understand what posix_fadvise() is allowing us to do. posix_fadvise(POSIX_FADV_WILLNEED) allows us to tell the kernel we will need a certain block in the future --- this seems much cheaper than a background reader. We know we will need the blocks, and telling the kernel can't hurt, except that there is overhead in telling the kernel. Has anyone measured how much overhead? I would be interested in a test program that read the same page over and over again from the kernel, with and without a posix_fadvise() call. Should we consider only telling the kernel X pages ahead, meaning when we are on page 10 we tell it about page 16? -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
