> 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
