a bit more precise MaxOffsetNumber

2011/4/30 Tomas Vondra <tv@fuzzy.cz>:

I've been digging in the sources, and I've noticed the MaxOffsetNumber
is defined (in storage/off.h) like this

 (BLCKSZ / sizeof(ItemIdData))

I guess it might be made a bit more precise by subtracting the header
like this

 (BLCKSZ - offsetof(PageHeaderData, pd_linp) / sizeof(ItemIdData))

although the difference is negligible (2048 vs 2042 for 8kB pages).

I guess we could do that, but I'm not sure there's much point. It's
also not entirely clear that this would actually work out to a win,
because of the issues discussed in the "When can/should we prune or
defragment?" section of src/backend/access/heap/README.HOT

We could probably figure this out with some careful testing, but I'm
not sure it's worth the effort.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dne 7.5.2011 04:02, Robert Haas napsal(a):

2011/4/30 Tomas Vondra <tv@fuzzy.cz>:

I've been digging in the sources, and I've noticed the MaxOffsetNumber
is defined (in storage/off.h) like this

(BLCKSZ / sizeof(ItemIdData))

I guess it might be made a bit more precise by subtracting the header
like this

(BLCKSZ - offsetof(PageHeaderData, pd_linp) / sizeof(ItemIdData))

although the difference is negligible (2048 vs 2042 for 8kB pages).

I guess we could do that, but I'm not sure there's much point. It's
also not entirely clear that this would actually work out to a win,
because of the issues discussed in the "When can/should we prune or
defragment?" section of src/backend/access/heap/README.HOT

We could probably figure this out with some careful testing, but I'm
not sure it's worth the effort.

No idea if it's worth the effort and if something can be broken by this
change. I've noticed this when trying to implement a more thorough check
of table contents vs. index. I was asking 'how many items can be stored
on a page' and I've noticed this.

Anyway I don't see how this could affect HOT updates? AFAIK this has
nothing to do with evaluation of free space on a page. It only affects
checking if the offset number may be valid (OffseNumberIsValid macro),
and code that needs to keep info about items on a page, as it usually
does something like this:

OffsetNumber unused[MaxOffsetNumber];

But yes, the amount of memory saved is negligible (12B) so the only
noticeable benefit might be catching some invalid offset numbers.

regards
Tomas