Обсуждение: 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

t.katsumata1122@gmail.com writes:
> I found a bug about estimating rows without pg_class.reltuples.
> ...
> 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) ?

You're absolutely right, that's a thinko.  Adjusted in HEAD.  I'm not
inclined to back-patch it though, since there's a risk of changing
plan choices which is something we don't like to do in stable branches
unless the planner is clearly doing the wrong thing.

            regards, tom lane

Hi,

Thank you for the fix.

2015-01-19 7:06 GMT+09:00, Tom Lane <tgl@sss.pgh.pa.us>:
> t.katsumata1122@gmail.com writes:
>> I found a bug about estimating rows without pg_class.reltuples.
>> ...
>> 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) ?
>
> You're absolutely right, that's a thinko.  Adjusted in HEAD.  I'm not
> inclined to back-patch it though, since there's a risk of changing
> plan choices which is something we don't like to do in stable branches
> unless the planner is clearly doing the wrong thing.
>
I think it's good to avoid undesirable risk.

Thank you very much again!

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