> 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
