the 20% rule

#31

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#32

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#33

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#34

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#35

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#36

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#37

David BL <davidbl (AT) iinet (DOT) net.au> writes:

Quote:

On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

Tim

--
tcross (at) rapttech dot com dot au

#38

On Jul 26, 1:59 pm, Tim X <t... (AT) nospam (DOT) dev.null> wrote:

Quote:

David BL <davi... (AT) iinet (DOT) net.au> writes:
On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

AFAIK in an index organised table, the ROWID is actually the primary
key which is used as a primary index. Your comment suggests that an
index is necessarily a secondary index which isn't always the case.

#39

On Jul 26, 1:59 pm, Tim X <t... (AT) nospam (DOT) dev.null> wrote:

Quote:

David BL <davi... (AT) iinet (DOT) net.au> writes:
On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

AFAIK in an index organised table, the ROWID is actually the primary
key which is used as a primary index. Your comment suggests that an
index is necessarily a secondary index which isn't always the case.

#40

On Jul 26, 1:59 pm, Tim X <t... (AT) nospam (DOT) dev.null> wrote:

Quote:

David BL <davi... (AT) iinet (DOT) net.au> writes:
On Jul 24, 10:01 pm, aark... (AT) gmail (DOT) com wrote:

The fastest way to retrieve rows from a table is to access the row
with exact row id. An
index is the second fastest way

I'm no expert in oracle, but my understanding is that it provides so
called heap organised tables or else index organised tables. The
above comment would seem to apply to the former not the latter.

Oracle provides a wealth of options with respect to table organisation,
indexes etc. Rowid is very fast because it identifies the exact row in
the table to retrieve. The problem is that you rarely know the rowid
without first having selected the row - its not like using an index
where you can say "give me all records where the field x = y". However,
if you do know the rowid of the row you are interested in, it is very
fast because you access it directly from the table and not by first
reading the index to get the table location and then reading it from the
table. At least, thats sort of my understanding in a siplistic way.

AFAIK in an index organised table, the ROWID is actually the primary
key which is used as a primary index. Your comment suggests that an
index is necessarily a secondary index which isn't always the case.