On Tue, Jan 14, 2014 at 2:03 PM, Gavin Flower <gavinflo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers