>> This paragraph leaves a *lot* to be desired from an accuracy perspective
>
> Really? Exactly which statements will you claim are incorrect?
That the int type is definitely faster on all platforms regardless of
circumstances. Especially the circumstance where the user really needs
a bigint and is doing some wonky workaround to use int instead, like the
newbie I'm chatting with on IRC right now, who did so specifically
because of that page of the docs.
Besides which, datatypes are not "faster". Specific operations with
them may be faster. They may require less storage and less RAM. But
if we call them "faster", then we're contributing to application
developer ignorance.
> I notice that your proposed rewrite omits the bit about bigint being
> slower, which I can only conclude means you haven't tested on any
> 32-bit platforms lately.
Hmmm. Yes, but that's more of an exception now than it is a common
circumstance. Change this:
"On very minimal operating systems the bigint type might not function
correctly, because it relies on compiler support for eight-byte
integers. On such machines, bigint acts the same as integer, but still
takes up eight bytes of storage. (We are not aware of any modern
platform where this is the case.)"
To this:
On 32-bit operating systems, or when PostgreSQL is complied 32-bit,
operations using bigint can be significantly slower than those with
integer. On very minimal operating systems the bigint type might not
function correctly, because it relies on compiler support for eight-byte
integers. On such machines, bigint acts the same as integer, but still
takes up eight bytes of storage. (We are not aware of any modern
platform where this is the case.)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
