Re: Some other things about contrib/bloom and generic_xlog.c - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Some other things about contrib/bloom and generic_xlog.c
Date
Msg-id CAB7nPqRrAgVhcxEb50KvbOsBkeDyAVvyLFQSN8PNcq1ik2p3gg@mail.gmail.com
Whole thread Raw
In response to Re: Some other things about contrib/bloom and generic_xlog.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 12, 2016 at 9:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... BTW, with respect to the documentation angle, it seems to me
> that it'd be better if GenericXLogRegister were renamed to
> GenericXLogRegisterBuffer, or perhaps GenericXLogRegisterPage.
> I think this would make the documentation clearer, and it would
> also make it easier to add other sorts of Register actions later,
> if we ever think of some (which seems not unlikely, really).

Funny thing. I just suggested the same just above :) With a second
routine to generate a delta difference from a page to keep the
knowledge of this delta in its own code path.

> Another thing to think about is whether we're going to regret
> hard-wiring the third argument as a boolean.  Should we consider
> making it a bitmask of flags, instead?  It's not terribly hard
> to think of other flags we might want there in future; for example
> maybe something to tell GenericXLogFinish whether it's worth trying
> to identify data movement on the page rather than just doing the
> byte-by-byte delta calculation.

Yes. Definitely this interface needs more thoughts. I'd think of
GenericXLogFinish as a more generic entry point.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Some other things about contrib/bloom and generic_xlog.c
Next
From: Craig Ringer
Date:
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0