On Tue, Jan 14, 2014 at 2:03 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
> Say a byte (this is arbitrary, it could be a single hint bit which meant
> "please, Please, PLEASE don't flush, if that is okay with you Mr
> Kernel..."), so strength would be S = (unsigned byte value)/256, so 0 <= S <
> 1.
>
> S = 0 flush now.
> 0 < S < 1 flush if the 'need' is greater than the S
> S = 1 never flush (note a value of 1 cannot occur, as max S = 255/256)
>
> Postgres could use low non-zero S values if it thinks that pages might still
> be useful later, and very high values when it is more certain. I am sure
> Postgres must sometimes know when some pages are more important to held onto
> than others, hence my feeling that S should be more than one bit.
>
> The kernel might simply flush pages starting at ones with low values of S
> working upwards until it has freed enough memory to resolve its memory
> pressure. So an explicit numerical value of 'need' (as implied above) is
> not required. Also any practical implementation would not use 'S' as a
> float/double, but use integer values for 'S' & 'need' - assuming that 'need'
> did have to be an actual value, which I suspect would not be reequired.
>
> This way the kernel is free to flush all such pages, when sufficient need
> arises - yet usually, when there is sufficient memory, the pages will be
> held unflushed.
Well, this just begs the question of what value PG ought to pass as
the parameter.
I think the alternate don't-need semantics (we don't think we need
this but please don't throw it away arbitrarily if there's no memory
pressure) would be a big win. I don't think we know enough in user
space to be more precise than that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
