Subject | Re: reorganise id's (OT) |
---|---|

Author | Adam |

Post date | 2006-05-15T23:54:23Z |

> this may seem like a stupid question but when i declare a table fieldNot at all stupid, probably the most on topic question in this thread

> in firebird as an integer, what is it internally by default? 64 or 32

> bits? if 32 bits, how do i change that to 64 bits?

so far ;)

Integer means 32 bit signed whole number.

BigInt means 64 bit signed whole number.

Generators return a BigInt, which will obviously cause an overflow if

you assign it to an integer Field when it has a value bigger than that

which would fit.

As far as integers (32 bit) go, you have

2^32 potential values, (2^31)ish are greater than 0.

This means the largest number you can store in a 32 bit integer field

is 2147483647. As someone has already pointed out, in a high volume

database, this will be a limitation in some systems. The common

misconception is that 64 bit is twice as big as a 32 bit integer. A 33

bit integer (if it existed) would be twice as big as a 32 bit integer,

and a 34 bit integer would be twice as big (as the 33 bit integer).

A 64 bit signed integer can store numbers between

-9223372036854775808 and 9223372036854775807

If you dish out, lets choose a big number, 100,000 per second (anyone

have hardware that could cope with that load), you would have about 3

million years to come up with a new solution. I will remind you at

this point, that each field must be by definition 8 bytes (at least,

you have null flags etc to consider as well). Lets put some context.

If you simply had a table with a BigInt field and no other fields, and

assuming that there was no record overhead (which there is), and you

managed to insert a record for every possible BigInt, you would need a

database that was around 7 million Terabytes.

NTFS has a limit of 256 Terabytes, and Firebird has several limits

that you will hit well and truly before this one. So I am not worried

about running out of generated values.

Adam