You could keep the bigint
PK, but for user interaction-related purposes (if that is why you want to reduce the length of the values) you could introduce a generated column that would return a string of characters representing your PK value in the desired form.
ALTER TABLE
YourTable
ADD
MyBigintIDInBaseN text
GENERATED ALWAYS AS MyDecimalToBaseNConversionFunction(MyBigintID) STORED
;
The conversion function would need to be a custom function (because I do not believe PostgreSQL offers a built-in one for this task), marked as IMMUTABLE
so that it can be used in a generated column expression.
That way you would continue using the bigint
PK internally, including as a sorting criterion where necessary and as a reference target for other tables' FKs. For display purposes, however, you would use the computed column.
If your custom representations of PKs need to be used as query arguments as well, it would be a good idea to create an index on the computed column to help the performance.
bigint
being verbose? Why would abigint
PK need to be readable or non-verbose to begin with? And what do you mean by base36 or base64 having the same number of bytes? Could you give us an example of abigint
value and its base36 or base64 equivalent that you believe would have the same number of bytes? It doesn't seem very clear what you are looking to achieve, to be honest. Welcome to the site, though!9223372036854775807
stored as a bigint requires 8 byte, encoded into base64 it'sOTIyMzM3MjAzNjg1NDc3NTgwNw==
which requires 29 bytes of storage. So you will increase your storage requirements substantially. And all that converting back and forth for no apparent reason won't make things faster as well. What exactly is the problem you are trying to solve with that seemingly useless approach?9223372036854775807
->1Y2P0IJ32E8E7
(36 base). The second one is shorter and takes less screen space.