> 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
