Re: Inconsistent use of relpages = -1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistent use of relpages = -1
Date
Msg-id 924396.1729278841@sss.pgh.pa.us
Whole thread Raw
In response to Inconsistent use of relpages = -1  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> As Corey discovered, and I re-discovered later, partitioned tables can
> have relpages=-1:
> ...
> Another problem is that it's inconsistent: sometimes it's 0 (before
> analyze) and sometimes -1. Views also don't have any storage, but
> relpages are always 0.
> ...
> I don't see any obvious reason that -1 is better than 0, or any code
> that checks for it, so I'm inclined to just use zero instead.

Hmm.  relpages = 0 should mean that the relation is (thought to be)
of size zero, which is certainly true for the partitioned table itself,
except that that reasoning should also mean that reltuples is zero.
But we don't do that:

regression=# select relname, relkind, relpages,reltuples from pg_class where relpages < 0;
    relname     | relkind | relpages | reltuples
----------------+---------+----------+-----------
 past_parted    | p       |       -1 |         0
 prt1           | p       |       -1 |       300
 pagg_tab       | p       |       -1 |      3000
 prt2           | p       |       -1 |       200
 pagg_tab1      | p       |       -1 |       150
 pagg_tab2      | p       |       -1 |       100
 prt1_e         | p       |       -1 |       300
 prt2_e         | p       |       -1 |       200
 pagg_tab_m     | p       |       -1 |      3000
 pagg_tab_ml    | p       |       -1 |     30000
 prt1_m         | p       |       -1 |       300
 prt2_m         | p       |       -1 |       200
 pagg_tab_ml_p2 | p       |       -1 |      8000
 pagg_tab_ml_p3 | p       |       -1 |     10000
 pagg_tab_para  | p       |       -1 |     30000
 plt1           | p       |       -1 |       300
 plt2           | p       |       -1 |       200
 plt1_e         | p       |       -1 |       300
 pht1           | p       |       -1 |       300
 pht2           | p       |       -1 |       200
 pht1_e         | p       |       -1 |       150
 prt1_l         | p       |       -1 |       300
 prt1_l_p2      | p       |       -1 |       125
 prt1_l_p3      | p       |       -1 |        50
 prt2_l         | p       |       -1 |       200
 prt2_l_p2      | p       |       -1 |        83
 prt2_l_p3      | p       |       -1 |        33
 prt1_n         | p       |       -1 |       250
 prt2_n         | p       |       -1 |       300
 prt3_n         | p       |       -1 |         0
 prt4_n         | p       |       -1 |       300
 alpha          | p       |       -1 |       360
 alpha_neg      | p       |       -1 |       180
 alpha_pos      | p       |       -1 |       180
 beta           | p       |       -1 |       360
 beta_neg       | p       |       -1 |       180
 beta_pos       | p       |       -1 |       180
(37 rows)

If we are going to put data into reltuples but not relpages,
I think I agree with setting relpages to -1 to signify
"unknown" (analogously to -1 for reltuples).  Otherwise it
looks like the table has infinite tuple density, which is
likely to bollix something somewhere.

I agree that not documenting this usage is bad, and not being
consistent about it is worse.  But I don't think switching
over to the previously-minority case will improve matters.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Inconsistent use of relpages = -1
Next
From: Mark Hill
Date:
Subject: msvc directory missing in PostgreSQL 17.0