From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_class.relpages/allvisible probably shouldn't be a int4 |
Date: | 2014-05-12 07:07:29 |
Message-ID: | 53707331.9060909@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/12/2014 12:30 AM, Andres Freund wrote:
>> >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.
> Yea, I am not wild for that either. I guess migrating to a postgres with
> a larger blocksize is the next step.
A larger block size won't buy you very much time either.
We could steal some bits from the OffsetNumber portion of an
ItemPointer. If we assume the max. block size of 32kb, and that each
Item takes at least 16 bytes, you only need 11 bits for the offset
number. That leaves 5 bits unused, and if we use them to expand the
block number to 37 bits in total, that's enough for 1 PB with the
default 8k block size.
But I concur that in practice, if you're dealing with 16TB tables, it's
time to partition.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-12 07:15:02 | Re: pg_class.relpages/allvisible probably shouldn't be a int4 |
Previous Message | Michael Paquier | 2014-05-12 07:07:25 | Re: Ignore src/tools/msvc/config.pl in code tree for MSVC compilation |