Andres Freund <and...@2ndquadrant.com> writes: > On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote: >> On Fri, May 9, 2014 at 1:50 PM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers