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
(althoughTOAST should reduce the need to have large tuples, since fields can be spread across multiple tuples).
BLCKSZmust be a power of 2. The maximum possible value of BLCKSZ is currently 2^15 (32768). This is determined by the
15-bitwidths of the lp_off and lp_len fields in ItemIdData (see include/storage/itemid.h). Changing BLCKSZ requires
aninitdb. */
#define BLCKSZ 8192
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
