Re: numRows()

On Sat, Dec 09, 2000 at 10:19:05PM -0600, Paul DuBois wrote: > At 3:12 PM +0300 12/8/00, Mikhail Zabaluev wrote: > >Hello Stig, > > > >On Fri, Dec 08, 2000 at 11:10 +0100, Stig S. Bakken wrote: > >> > >> "James L. Pine" wrote: > >> > > >> > On Fri, 8 Dec 2000, Stig S. Bakken wrote: > >> > > >> > > What does affectedRows return for Oracle when you do "delete from > >> > > table"? Mysql_affected_rows() returns 0 in this case. This can be > >> > > emulated by sneaking in a "select (*) from" first, but > >> > > that's not giving > >> ^ > >> There's a "count" missing up here ----' > > > >Queries like this are believed to be very fast in MySQL, so why not? > > Actually, SELECT COUNT(*) FROM tbl_name is very fast normally, except if > your table is a BDB table. Apparently no magic number is stored in the > underlying files for that kind of table, so SELECT COUNT(*) is actually > kind of slow. I believe there may be some work afoot on fixing this in > future versions. when using oracle "select count(*)" causes a full table-scan:-( if you do "select count(*) from table where table_primary_key > 0" it still does an index scan (far faster - but still sub-optimal). i don't know why they do it, but as a matter of fact, they do. so (atleast when using oracle) you should not depend on any numRows(). tc > > -- > Paul DuBois, paul@snake.net > > -- > PHP Extension and Add-on Repository (PEAR) mailing list. > Documentation can be found at http://pear.php.net/doc/pear.html > To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the > mail address you subscribed with. > >