Actually, I think pg_dump with the -o flag keeps oid's, therefore allowing
me to keep referential integrity after backup.
> > First, I tried searching tables by their oid, but explain returned
> > sequential scans. Second, I tried specifing the oid as the primary key in
> > a table, but the oid column wasn't found. Finally, I created an index for
> > oid which worked fine. In the end, I feel I'm back to square one having to
> > use the same index as with my char(32) id's. It seems my only gain would
> > be 28 bytes per row and no speed gain, apart perhaps for building the
> > index which should be a bit slower for a char(32) datatype rather than an
> > integer.
>
> Using oid's is not a good idea, as they don't automatically get dumped with
> pg_dump. And once your referential integrity gets screwed up and you are
> using oid's you are really in a mess, as you cannot change oids. Use a serial
> field to generate a key for every row, which generates you a sequence of
> integers. It is much better than oids at a cost of 4 bytes.
>
> As far as i have understood you need an index if you want to avoid a
> sequential scan as tuples are not stored in a hierarchy in the table. Only in
> indexes do you get b-trees etc. So define your serial field as a primary key
> and you are done. And comparing 4-byte ints is much faster than comparing
> 32-byte text fields, that's for sure.
>
> Adriaan
>
>
