> On 26-1-2013 14:42, Thomas Steinmaurer wrote:
>>> (Using FB 1.5)
>>>
>>> Do inserts in FB benefit from ordered or sequential PK?
>>> Please allow me to clarify. I intend to use High/Low for table PKs. With this approach, it is very possible that PKs will not be in sequential order as they are inserted into the db. Will this be an issue in FB?
>>>
>>> I based this question on this article:
>>> http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database
>>
>> Interesting reading. Thanks for sharing!
>>
>> I once run a test with insertion performance in Firebird 2.5 with a)
>> sequential PK values coming from a generator and b) via the built-in
>> function giving me a UUID.
>>
>> For me, Firebird's (bulk) insertion performance had always been better
>> with sequential PK values, because with somehow "random" values, for
>> actualizing the index tree, index pages might need to be re-read from
>> disk again etc. You can somehow tackle that with a larger page cache,
>> which allows to cache more index pages, but still, sequential PK values
>> perform better, at least for me.
>
> Don't forget the additional overhead of the bigger size of a UUID versus
> an INTEGER (4x) or BIGINT (2x) (assuming storage of the UUID in a
> CHAR(16) CHARACTER SET OCTETS).

Absolutely!

Not that worse with random integers, but still worse than sequential
integers. Unluckily, I currently don't find the test results.

Regards,
Thomas