At 08:39 PM 11/27/00 -0500, Bruce Momjian wrote:
>[ Charset ISO-8859-1 unsupported, converting... ]
>> If it breaks anything in PostgreSQL I sure haven't seen any evidence -- the
>> box this database is running on gets hit pretty hard and I haven't had a
>> single ounce of trouble since I went to 7.0.X
>
>Larger block sizes mean larger blocks in the cache, therefore fewer
>blocks per megabyte. The more granular the cache, the better.
Well, true, but when you have 256 MB or a half-gig or more to devote to
the cache, you get plenty of blocks, and in pre-PG 7.1 the 8KB limit is a
pain for a lot of folks.
Though the entire discussion's moot with PG 7.1, with the removal of the
tuple-size limit, it has been unfortunate that the fact that a blocksize
of up to 32KB can easily be configured at build time hasn't been printed
in a flaming-red oversized font on the front page of www.postgresql.org.
THE ENTIRE WORLD seems to believe that PG suffers from a hard-wired 8KB
limit on tuple size, rather than simply defaulting to that limit. When
I tell the heathens that the REAL limit is 32KB, they're surprised, amazed,
pleased etc.
This default has unfairly contributed to the poor reputation PG has suffered
from for so long due to widespread ignorance that it's only a default, easily
changed.
For instance the November Linux Journal has a column on PG, favorable but
mentions the 8KB limit as though it's absolute. Tim Perdue's article on
PHP Builder implied the same when he spoke of PG 7.1 removing the limit.
Again, PG 7.1 removes the issue entirely, but it is ironic that so many
people had heard that PG suffered from a hard-wired 8KB limit on tuple
length...
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
