Re: Some other things about contrib/bloom and generic_xlog.c
От | Michael Paquier |
---|---|
Тема | Re: Some other things about contrib/bloom and generic_xlog.c |
Дата | |
Msg-id | CAB7nPqRrAgVhcxEb50KvbOsBkeDyAVvyLFQSN8PNcq1ik2p3gg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Some other things about contrib/bloom and generic_xlog.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: