Excerpts from Kevin Grittner's message of mié ene 04 04:12:43 -0300 2012: > "Kevin Grittner" wrote: > > > if we define sum1 and sum2 as uint I don't see how we can get an > > overflow with 8k byes > > I feel the need to amend that opinion. > > While sum1 only needs to hold a maximum of (BLCKSZ * 255), which > would be adequate for a BLCKSZ up to 16 MB, sum2 needs to hold up to > a maximum of ((BLCKSZ * (BLCKSZ + 1) / 2) * 255) so a 32-bit unsigned > isn't even good for an 8 KB block size. A uint64 for sum2 can handle > BLCKSZ up to 256 MB. So we could define sum1 as uint (which is > presumably either uint32 or uint64) and sum2 as uint64 and for a > BLCKSZ up toe 16 MB we still don't need to find the modulo 255 > numbers until we're done adding things up. > > Does anyone think we need to support anything bigger than that? > Making them both uint64 would support a BLCKSZ up to 256 MB without > needing to do the division inside the loop. but it might be slightly > slower on 32-bit builds.
We don't support BLCKSZ higher than 32k anyway ... saith pg_config.h: /* Size of a disk block --- this also limits the size of a tuple. You can set it bigger if you need bigger tuples (although TOAST should reduce the need to have large tuples, since fields can be spread across multiple tuples). BLCKSZ must be a power of 2. The maximum possible value of BLCKSZ is currently 2^15 (32768). This is determined by the 15-bit widths of the lp_off and lp_len fields in ItemIdData (see include/storage/itemid.h). Changing BLCKSZ requires an initdb. */ #define BLCKSZ 8192 -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
