On Wed, Dec 18, 2013 at 8:33 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 17, 2013 at 12:35 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > 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.
Few observations: 1. pg_prewarm.control +# pg_buffercache extension Wrong name. 2. +pg_prewarm(regclass, mode text default 'buffer', fork text default 'main', + first_block int8 default null, + last_block int8 default null) RETURNS int8 { .. int64 first_block; int64 last_block; int64 nblocks; int64 blocks_done = 0; .. } is there specific reason to keep parameters type as int8, shouldn't it be uint32 (BlockNumber)? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers