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.katsumata1122@gmail.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