CombGuidIdGeneration is not required

[dariogriffo]

I have been reading about how postgres treat uuid in the last couple of days, this is just a note:
from the official docs here

CLUSTER instructs PostgreSQL to cluster the table specified by table_name based on the index specified by index_name. The index must already have been defined on table_name. When a table is clustered, it is physically reordered based on the index information. Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered. That is, no attempt is made to store new or updated rows according to their index order. (If one wishes, one can periodically recluster by issuing the command again. Also, setting the table's FILLFACTOR storage parameter to less than 100% can aid in preserving cluster ordering during updates, since updated rows are kept on the same page if enough space is available there.)

I think the missunderstanding comes from us thinking: "Postgres stores uuids this way" and we translate to "Postgres has clustered indexes" because we are used to clustered indexes in SQLServer.
Just a note, that this is not required, unless there is a regular update on the tables to cluster them.
Hope this makes sense. By the way, thanks a lot for the project, is amazing!

[cocowalla]

I'm not part of the Marten project team (just a happy user and very occasional contributer), but I do remember scratching my head a while back when I saw the GUID comb support added - as it happened, I'd recently tested this out in Postgres for myself, and found no performance benefits to GUID comb over regular, random UUIDs. I guess others must have ran their own tests with a different outcome to decide to add this support, so maybe there was something wrong with my test setup 🤷‍♂️

[dariogriffo]

From a technical point of view there shouldn't if the chosen index for the id is the appropiate (by default B-tree)