Subject | Re: [firebird-support] Benefit from Sequential Insert of High/Low PK |
---|---|
Author | Mark Rotteveel |
Post date | 2013-01-26T13:48:51Z |
On 26-1-2013 14:42, Thomas Steinmaurer wrote:
an INTEGER (4x) or BIGINT (2x) (assuming storage of the UUID in a
CHAR(16) CHARACTER SET OCTETS).
Mark
--
Mark Rotteveel
>> (Using FB 1.5)Don't forget the additional overhead of the bigger size of a UUID versus
>>
>> 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.
an INTEGER (4x) or BIGINT (2x) (assuming storage of the UUID in a
CHAR(16) CHARACTER SET OCTETS).
Mark
--
Mark Rotteveel