Re: pg_rewarm status
От | Robert Haas |
---|---|
Тема | Re: pg_rewarm status |
Дата | |
Msg-id | CA+TgmoazJdHgF7w6F80TBeabYA_3TCehe55DvZtUrovep+wPVg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_rewarm status (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: pg_rewarm status
Re: pg_rewarm status |
Список | pgsql-hackers |
On Tue, Dec 17, 2013 at 12:35 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > Since it doesn't use directIO, you can't warm the PG buffers without also > warming FS cache as a side effect. That is why I like 'buffer' as the > default--if the data fits in shared_buffers, it warm those, otherwise it at > least warms the FS. If you want to only warm the FS cache, you can use > either the 'prefetch' or 'read' modes instead. All right, here is an updated patch. I swapped the second and third arguments, because I think overriding the prewarm mode will be a lot more common than overriding the relation fork. I also added defaults, so you can do this: SELECT pg_prewarm('pgbench_accounts'); Or this: SELECT pg_prewarm('pgbench_accounts', 'read'); I also fixed some oversights in the error checks. I'm not inclined to wait for the next CommitFest to commit this, because it's a very simple patch and has already had a lot more field testing than most patches get before they're committed. And it's just a contrib module, so the damage it can do if there is in fact a bug is pretty limited. All that having been said, any review is appreciated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: