Prereading using posix_fadvise (was Re: Commitfest patches) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Prereading using posix_fadvise (was Re: Commitfest patches)
Date
Msg-id 47ECF499.5050205@enterprisedb.com
Whole thread Raw
In response to Re: Commitfest patches  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Prereading using posix_fadvise (was Re: Commitfest patches)
List pgsql-hackers
Gregory Stark wrote:
> I described which interfaces worked on Linux and Solaris based on empirical
> tests. I posted source code for synthetic benchmarks so we could test it on a
> wide range of hardware. I posted graphs based on empirical results. I posted
> mathematical formulas analysing just how much preread would be expected to
> exercise a raid array fully. I'm not sure what else I can do to effect a more
> thorough examination.

I'm sure posix_fadvise is a win in the case where it's supposed to help: 
a scan that does a lot of random reads, on RAID array. And you've posted 
results demonstrating that. What we need to make sure is that there's no 
significant loss when it's not helping.

It seems that the worst case for this patch is a scan on a table that 
doesn't fit in shared_buffers, but is fully cached in the OS cache. In 
that case, the posix_fadvise calls would be a certain waste of time.

That could be alleviated by deciding at plan time whether to preread or 
not, based on effective_cache_size.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: advancing snapshot's xmin
Next
From: Simon Riggs
Date:
Subject: Re: advancing snapshot's xmin