On Wed, Feb 1, 2017 at 1:17 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
And benchmarks like dbt-1 have a pre-warming period added in the test itself where the user can specify in a number of seconds to linearly increase the load from 0% to 100%, just for filling in the OS and PG's cache... This feature would be helpful. > 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. Having that working fast would be really nice. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
