August 4, 2005 at 11:37 pm
hi folks,
The post above gives an example why partitioning isn't a good idea, when you have a unique indexable column for your queries.
Partitioning = 2 + 3 + 2 + 2 reads. If you note, the 3 is on part_3 where we know the record is located. So 2 reads for each index, and 1 read to get to the row in thhe table.
Single table = 3 reads (2 reads for the index and 1 for the table).
Unless you are doing a FULL table scan everytime on your table (which is very bad for large tables), partitioning isn't going to help your queries.
August 4, 2005 at 11:38 pm
Based on the requirements I would have a single table.
Index on barcode. Another index on timestamp.
Consider having a purging/archiving mechanism to move the old data entirely out of the database. Not to another table, out of the db.
August 4, 2005 at 11:40 pm
Based on the requirements I would have a single table.
Index on barcode. Another index on timestamp.
Consider having a purging/archiving mechanism to move the old data entirely out of the database. Not to another table, out of the db.
August 4, 2005 at 11:40 pm
Based on the requirements I would have a single table.
Index on barcode. Another index on timestamp.
Consider having a purging/archiving mechanism to move the old data entirely out of the database. Not to another table, out of the db.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply