Thread: 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