| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Some other things about contrib/bloom and generic_xlog.c |
| Date: | 2016-04-12 13:33:05 |
| Message-ID: | CAPpHfduWpq22DHW+436p-rhz-xgf7HG=3nYts-j=cYjGyZ6MfA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 12, 2016 at 3:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).
>
> 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.
I agree with both of these ideas. Patch is attached.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| Attachment | Content-Type | Size |
|---|---|---|
| generic-xlog-register.patch | application/octet-stream | 11.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2016-04-12 13:36:24 | Re: Some other things about contrib/bloom and generic_xlog.c |
| Previous Message | Pavel Stehule | 2016-04-12 13:15:21 | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |