 | |
Index organized table
comp.databases.oracle.server comp.databases.oracle.server
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Index organized table -
06-15-2008
, 02:49 AM
#2
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#3
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#4
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#5
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#6
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#7
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#8
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
#9
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. |
that size at all unless you are expecting this to grow to gigabytes
shortly.
Quote:
|
There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. |
Oracle version? With the information you have presented so far it is
impossible to come up with a definitive answer.
Quote:
|
Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
spent more space because the secondary index needs to store the PK to
identify rows. Depending on the size (# of columns as well as types)
the IOT solution might actually take more space especially if you add
more indexes.
Note also that IOT's make some administrative tasks harder. For
example, you cannot just drop the PK constraint as easily as you can do
with regular tables.
Kind regards
robert
#10
| |||
| |||
|
|
I'm thinking about some changes in my DB app. to switch one table to an IOT. That table has pri. key wich is always stored in sequence order (in inserting new row). Currently, that table is 240Mb big (with more than 2 mil. rows) with an average row size of 100 bytes. |
that size at all unless you are expecting this to grow to gigabytes
shortly.
Quote:
|
There is an pri. key index and a single B-tree index. Size of an pri. key index at the moment is 110Mb. |
Oracle version? With the information you have presented so far it is
impossible to come up with a definitive answer.
Quote:
|
Is it reccomended to use IOT in my case? How would it affect insert time for a single row? |
spent more space because the secondary index needs to store the PK to
identify rows. Depending on the size (# of columns as well as types)
the IOT solution might actually take more space especially if you add
more indexes.
Note also that IOT's make some administrative tasks harder. For
example, you cannot just drop the PK constraint as easily as you can do
with regular tables.
Kind regards
robert
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.