PostgreSQL B-tree, good monotonic values? I am creating a unique ID generator for my application. I am reading everywhere that monotonic keys make life easier for the b-tree. I generate an ID by combining a time part and a random part, the result is a BIGINT. 30 inserts over a month time would look like:
161382496505555475
161383496513869363
161384566521269728
161387696534951408
161391066542917771
161395676557845188
161396876568927786
161403566572243244
161406876581461654
161411576592302253
161432366601557433
161454566612380546
161497816626330847
161498126638855404
161522016645286994
161542136651268281
161552156668048334
161556516672713275
161567476682846578
161587696692945392
161598426706622187
161599986719703849
161602466723494896
161633486735133538
161634866748327052
161654886754576805
161665966765069819
161686876779287376
161688676786669774
161699126792749601

The first 11 digits are always sequential, the last 7 digits are always random.
Would this work well on a PostgreSQL 12 index?
With B-Tree indexes, more importantly is the cardinality of the data you're indexing. The more unique the data is in the index, generally the better candidate it is for a B-Tree index because it'll result in a much more full tree with many branches and leaves. A very non-unique field, like a boolean based field, will always only have two distinct values, and therefore is very repetitive resulting in two short but wide branches and doesn't filter down the data as much as a more unique field.
Since you're planning to index a BIGINT field with randomized values, it should lead to very unique data and the B-Tree index should perform very well, regardless of the monotonicness of those values. Additionally, if you're only inserting 30 values a month, your table must be tiny so you should have no worries at all regarding using a B-Tree index. B-Tree indexes handle billions of rows just fine.
To answer your actual question, yes monotonic values in a B-Tree index reduce fragmentation initially and therefor are more efficient, but again this is probably a minimal concern based on the fact that your values will be very unique and your overall amount of data being tiny.