On Tue, Jan 31, 2017 at 1:48 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > I partially agree with this paragraph, at least there are advantages > to do so for cases where the data fits in shared buffers. Even for > data sets fitting in RAM that can be an advantage as the buffers would > get evicted from Postgres' cache but not the OS. Now for cases where > there are many load patterns on a given database (I have some here), > that's hard to make this thing by default on.
Well, the question even for that case is whether it really costs anything. My bet is that it is nearly free when it doesn't help, but that could be wrong. My experience running pgbench tests is that prewarming all of pgbench_accounts on a scale factor that fits in shared_buffers using "dd" took just a few seconds, but when accessing the blocks in random order the cache took many minutes to heat up. Now, I assume that this patch sorts the I/O (although I haven't checked that) and therefore I expect that the prewarm completes really fast. If that's not the case, then that's bad. But if it is the case, then it's not really hurting you even if the workload changes completely. Again, I'm not really arguing for enable-by-default, but I think if this is well-implemented the chances of it actually hurting anything are very low, so you'll either win or it'll make no difference. -- 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
