Re: make BufferGetBlockNumber() a macro
| От | Tom Lane |
|---|---|
| Тема | Re: make BufferGetBlockNumber() a macro |
| Дата | |
| Msg-id | 16578.1017701946@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | make BufferGetBlockNumber() a macro (Neil Conway <nconway@klamath.dyndns.org>) |
| Ответы |
Re: make BufferGetBlockNumber() a macro
|
| Список | pgsql-patches |
Neil Conway <nconway@klamath.dyndns.org> writes:
> The attached patch re-implements BufferGetBlockNumber() as a macro,
> for performance reasons.
The trouble with this is that it forces storage/buf_internals.h to
become part of bufmgr.h, thereby completely destroying any information
hiding that we had from the division of the two headers --- any client
of bufmgr.h might now access bufmgr internal stuff without noticing
that it was doing wrong.
I am not convinced that BufferGetBlockNumber is a bottleneck anyway;
at least not if you don't have Assert checking enabled.
There are a few places that do things like
ItemPointerSet(&(tuple->t_self), BufferGetBlockNumber(buffer), offnum);
which I believe results in two calls to BufferGetBlockNumber because of
the way BlockIdSet is coded. This would be good to clean up, but it's
BlockIdSet's problem not BufferGetBlockNumber's.
> It also adds an assertion that should probably
> be present.
FWIW, BufferIsPinned also checks BufferIsValid; you do not need both.
regards, tom lane
В списке pgsql-patches по дате отправления: