BUG #12584: small bug about estimation of rows

The following bug has been logged on the website:

Bug reference: 12584
Logged by: Tomonari Katsumata
Email address: t(dot)katsumata1122(at)gmail(dot)com
PostgreSQL version: Unsupported/Unknown
Operating system: CentOS 6.4 x86_64
Description:

Hello,

I found a bug about estimating rows without pg_class.reltuples.
An empty table has NULL on its pg_class.reltuples.

If PostgreSQL couldn't find pg_class.reltuples, the estimated rows
are calculated by pagesize, size of the data and so on.

Below is simple example.

========
testdb=# CREATE TABLE tbl (i bigint);
CREATE TABLE
testdb=# EXPLAIN SELECT * FROM tbl;
QUERY PLAN
-------------------------------------------------------
Seq Scan on tbl (cost=0.00..31.40 rows=2140 width=8)
(1 row)
========

"rows=2140" is calculated at estimate_rel_size function of plancat.c like
this.

========
plancat.c from master source.
508 int32 tuple_width;
509
510 tuple_width = get_rel_data_width(rel,
attr_widths);
511 tuple_width +=
sizeof(HeapTupleHeaderData);
512 tuple_width +=
sizeof(ItemPointerData);
513 /* note: integer division is
intentional here */
514 density = (BLCKSZ -
SizeOfPageHeaderData) / tuple_width;
========

It should be using sizeof(ItemIdData) at line 512, so the estimated rows
should be "rows=2260".

I could understand ignoring alignment of data here from comment of the
source code,
but I couldn't find the reason of using sizeof(ItemPointerData) at this
point.

Usually this would not cause big problem, but it seems odd to me.
Is there any reason to use sizeof(ItemPointerData) ?

regards,
--------------------
Tomonari Katsumata