this is what i meant

> If you don't need an OID, don't include it. IIRC, bit(4) will be 8
> bytes due to being variable length. If you want to store small numbers,
> maybe smallint (2 bytes) is more useful.

What I acually meant was the OID... Is smallint(2) the smalles size I
can allocate?  If I cannot allocate 4Bit or less directly this implies
8 * 2Byte in comparison to just 8 *4 Bit space requirements which is
HUGE difference in my scenario! So the question is:
Can I explicitly store 4 Bit (FIXED lenght) in a column without
"wasting" space?

> You can index anything and everything. PostgreSQL doesn't have a
> ROWID so I'm not sure what you're referring to here.
I am currently thinking about the database size. Therefore I nee the
exact rowsize and the size of the index to design my database. Even if
postgres does not use explicit rowids, there has to be some sort of
reference for each key in the index to the row it refers to. In Oracle
this is done using a rowid and I need the size for such a reference in
Postgres.

> Well, PostgreSQL allows you to create your own index types if you don't
> like b-trees. However, b-tree should be able to do what you want. I
> have no idea what a "real disk-resident Bitmap-Index" would look like
> so I can't comment on that.

A disc resident BitIndex (as Oracle offers it) is stored in the
dababase, which means, that you need as many bits for an index entry as
there are different attribute values for the indexed column (in my case
15). If the attribute value in column j is set to i, then the ith bit
is set to one and all the other ones are zero (actually these are ALL
possible Bitvectors --- Postgres produces one of those "columns"
dependend on the query). In my case this would save storage space for
the index, because I would only need 2 Bytes for each index entry. In
case of a BTree I need space for the key (4Bit) AND for the pointer(s)
(4 Byte) in the index' tree-structure.

> BTW, you using <= on a bit type, which seems wierd to me. Shouldn't
> they be numbers?
Actually the bittypes just represent hashbins coding real distances of
a distance descriptor (80 different distances) from molecular biology.
Once again this is done to reduce the space complexity (from float down
to 4 Bit --- which still represent the situation detailed enough). This
needs to be done because of the massive amount of data.


> If you can't think of a reason why you need OIDs, don't use them. The
> latest release of PostgreSQL phases them out for user tables anyway
> since they're not actually useful 99% of the time.

Alright... so I do not need the OIDs! But as for as I know I need OIDs
if I want to use a BLOB for the complete information, which I would
like to do once again to reduce the size of each row in the table (from
80 *4 Bits down to just 1 Pointer to the BLOB).

Thanks for any suggestions and/or further information