Question

I’m working on a project where there are multiple schema within a postgres database. At times I’ve to move some schema from one database to another. In my data structure I’m using a lot of oid columns which are causing problems during the movement because of oid clashing with existing oid in the new database to which a schema is moved.

I’m using the following commands to take the backup and restore the schema

pg_dump -f <file> -F t -o --blobs -n <schema> <database>

pg_restore -d <database> -F t -v <file>

All my files are below 100MB size, most of them will be in few KB in size so I’m thinking about using bytea data type instead of oid.

Is it a good move or a bad one?

As per the documentation if the file size is very large then it is recommending to use oid but in my case the files will be small.

Is there any performance impact if I use bytea instead of oid like indexing/search?

Answer 1

The reason to not use oid (or serial) for situations like this is that they increment serially, so it’s not surprising you have clashes.

I am not 100% sure, but reading the docs, it looks like bytea is implemented similar to varchar in terms of storage space so the index size, search speed and storage requirements will be similar. That is to say, it will take more space and be slower that using integer or long values. But, how much slower and if it matters for your use case, I am not sure.

Why not try an integer (or long), but use a random value instead of a sequential one first? If that doesn’t work, I would recommend the built in uuid type rather than trying to fill up a byte array with your own generated data.