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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs