Re: pg_rewarm status

On Wed, Dec 18, 2013 at 8:33 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Dec 17, 2013 at 12:35 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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