Dean Harding wrote:

Like I said, the ROWID in Oracle is the *physical address* of the row.
It's made up of three parts: datafile, block and offset.  If you say:

select * from some_table where rowid='RRRBBBBBBFFF';

In that case, I'm more confused about why anyone would want to specify "ORDER BY rowid" since it buys you nothing over not using ORDER BY at all (since ORDER BY was a significant part of the early messages in this thread). However, the use of "rowid='RRRBB....';" in your code can only possibly be useful in very limited cases, otherwise you're duplicating the effort of maintaining an index yourself somewhere in your own code (and moving the entire operation of your code into O(log(n)) space instead of O(1)).
I can only understand the equivalent of doing an insert, grabbing its rowid (I'm presuming the existence of an equivalent to SELECT last_rowid() or some such command), then reusing that value for grabbing the data later or as a reference in another table, but again, this goes around referential integrity (unless I'm missing something again) and buys almost nothing but possibly faster inserts. I say possibly because I have no information to show that an INSERT is faster or slower on an unindexed table in Oracle than it is on an "unsigned int auto_increment primary key" table in MyISAM format, for example.


an O(1) operation - it doesn't matter how many rows you've got in the
table, you could have a billion rows and it's still the same amount of
time as if you had 1 row.

That of course depends entirely on the disk subsystem's average seek time, memory structures and a few other components. These factor into doing an indexed lookup as well of course; but as CPU cycles devoted to backend database operations go, it is an 'easier' operation.

(I'm assuming you're not disputing my O(log(n)) for access via an index,
since that's a pretty fundamental number).

Of course, but what I'm having more of a problem with is getting "advantages" of the described rowid feature for the sake of "wanting" it. I'm not saying that I need to personally think its useful to me, but to anyone at all. I get the impression that the average MySQL AB developper doesn't see it as being actually useful because of implementation, but I could easily be very off-base there. PS, thanks for the very good description (hopefully accurate) of how rowid does work in Oracle.

You don't save the pointer to disk when you write your data to disk
(because it doesn't make sense to).  It's the same with a rowid.

Understood; thank-you.

Again, I'd love to see an insert speed timing comparison ...

... and I have the feeling in my programmer's mind that some of these seeming advantages can be done programmatically in MySQL without exposing the equivalent of rowid to the database programmer, just as it uses indexes automatically without needing them to be specified (usually ;-) ). Any thoughts?

--
Michael T. Babcock
C.T.O., FibreSpeed Ltd.
http://www.fibrespeed.net/~mbabcock



---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to