On Wed, Dec 18, 2013 at 6:07 PM, Cédric Villemain <cedric@2ndquadrant.fr> wrote:
> In the case of effective_io_concurrency, however, this may not work as well as
> expected, IIRC it is used to prefetch heap blocks, hopefully the requested
> blocks are contiguous but if there are too much holes it is enough to fill the
> ring very quickly (with the current max value of effective_io_concurrency).
Yeah, we'd need to figure out how big the ring would need to be for
reasonable values of effective_io_concurrency.
>> When the prefetch process starts up, it services requests from the
>> queue by reading the requested blocks (or block ranges). When the
>> queue is empty, it sleeps. If it receives no requests for some period
>> of time, it unregisters itself and exits. This is sort of a souped-up
>> version of the hibernation facility we already have for some auxiliary
>> processes, in that we don't just make the process sleep for a longer
>> period of time but actually get rid of it altogether.
>
> I'm just a bit skeptical about the starting time: backend will ReadBuffer very
> soon after requesting the Prefetch...
Yeah, absolutely. The first backend that needs a prefetch probably
isn't going to get it in time. I think that's OK though. Once the
background process is started, response times will be quicker...
although possibly still not quick enough. We'd need to benchmark this
to determine how quickly the background process can actually service
requests. Does anybody have a good self-contained test case that
showcases the benefits of prefetching?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
