Re: pg_class.relpages/allvisible probably shouldn't be a int4

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote:
>> On Fri, May 9, 2014 at 1:50 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> And adding a proper unsigned type doesn't sound like a small amount of work.

>> Perhaps not, but it's overdue. We ought to have one.

> Maybe. But there's so many things to decide around it that I don't think
> it's a good prerequisite for not showing essentially corrupted values in
> a supported scenario.

It's a lot harder than it sounds at first; see past discussions about how
we could shoehorn one into the numeric type hierarchy. And think about
how C expressions that mix signed and unsigned inputs tend to give
surprising results :-(

The bigger picture though is that it's hard to get excited about this
particular scenario, because if you are up to the point where your table
size overflows int32, you are less than a factor of 2 away from the hard
limit of BlockNumber, and will therefore soon have much bigger problems to
worry about than whether pg_class.relpages prints confusingly. My advice
to anyone who reported this from the field would certainly be "time to
think about partitioning that table". So if I were to take Andres'
complaint seriously at all, I'd be thinking in terms of "do we need to
widen BlockNumber to int64?", not "how do we make this print as
unsigned?". But I doubt such a proposal would fly, because of the
negative impact on index sizes.

A possible cosmetic fix is to just clamp the value vacuum/analyze
will store into relpages at INT_MAX, while scaling reltuples so that
the all-important reltuples/relpages ratio stays at reality. But
that might be harder than it sounds too, because of the moving
average tracking behavior for reltuples. And it'd be a code path
that gets no meaningful testing :-(

regards, tom lane