<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Which distro?<br>><br>> I use Ubuntu 6.10 and if you install PHP 5, 5.1.6 is the default you get.
<br>> This makes<br>> it harder to use 5.2 (custom compile, ...etc.)<br>><br>> If you have working code, I can verify whether I have the same problem or<br>> not on my test server.<br><br>I also run Ubuntu Edgy (
6.10), which is how I ran into this problem. After spending 4 hours trying to figure out why I was segfaulting only sometimes on a session-load query, I checked with the php-general development list and was told that 5.1.6
had a lot of segfault issues. I found a 3rd party repository and installed 5.2.1 and the segfaults all went away.</blockquote><div><br>Interesting. Out of three Ubuntu installs, all of them 5.1.6, only one segfaults, but
<br>that is because of eAccelerator. I have a client who uses Fedora Core 4, and their<br>PHP segfaulted every hour or two when we put in eAccelerator. We compiled <br>PHP 5.2.1 and eAccelerator, and all the problems went away.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> My concern here is that all db_num_rows() cases become two queries for<br>
> people using MySQL (the vast majority) as well as PostgreSQL (it has<br>> pg_num_rows()).<br><br>Not all, actually. At least one (in sess_write()) really should have been a count query in the first place as it's never iterated. I'm not sure how many cases will simply become 2 queries and how many will be able to stay as one with some logic refactoring. I don't think I'll know that until I start doing so.
</blockquote><div><br>I guess the safest way is to benchmark selected page loads, and see what the<br>impact is. But from the looks of it, it seems two queries is slower than just one.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> If these are index only queries, then it may not be a big deal, but<br>> anything more (which we have a lot of), would incur a significant performance penalty.<br>> It also affects large sites using InnoDB which is notorious for very slow SELECT
<br>> COUNT(*).<br>><br>> See a benchmark here:<br>><br>> <a href="http://2bits.com/articles/mysql-innodb-performance-gains-as-well-as-some-pitfalls.html">http://2bits.com/articles/mysql-innodb-performance-gains-as-well-as-some-pitfalls.html
</a><br><br>Wouldn't InnoDB be just as slow running a full select statement and then doing a num_rows() on it as it would be doing a COUNT() query in the first place? It still has all the WHERE-ing to do. More specifically, MyISAM is a special case where count(*) is faster than it otherwise would be in any other situation. It's not that InnoDB is slow, it's that MyISAM is fast. :-)
</blockquote><div><br>But at present, db_num_rows() is a wrapper around mysql_num_rows() which does not<br>do a COUNT(*) query, so it is fast on both MyISAM and InnoDB. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Still, though, I suspect that at least some cases will not get hosed if we refactor properly; some don't need to be full normal queries in the first place, and I am not opposed to adding additional indexes where appropriate.
</blockquote><div><br>Agreed. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Not sure what else can be done here. Is there a way to sneek in a pass
<br>> thru<br>> function<br>> (mysql_num_rows() in this case) like ODBC for example allows?<br><br>I'm not sure what ODBC does. Can you elaborate?</blockquote><div><br>It has been a while, but in ODBC, there is a pass-thru query mode, where instead
<br>of writing portable queries that work with any ODBC supported database (and write<br>to the lowest common denominator), you can tell ODBC to just pass the db-engine<br>specific query through and get back the results. This allows queries that are
<br>optimized for a certain db engine to be executed, and/or queries that use features<br>in the engine your are using.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm pretty sure one can't call mysql_* functions on a PDOStatement object.</blockquote><div><br>Too bad. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Option D) : File a feature request against PDO to include a numRows()<br>> method,<br>> but that is not a quick solution.<br><br>That's the same as C for the forseeable future. Such an addition wouldn't be added until at least PHP
5.3, I imagine, which is who knows when. And even at that, it would require a lot of C-level implementation to emulate num_rows on all databases, whether they natively support it or not.</blockquote><div><br>So file an issue anyway, but we all won't hold our breath on it.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I am hoping I can get this into Drupal 6, but time will tell if I can get
<br>> it ready in time.<br>><br>><br>> Ubuntu Feisty (due later in April) will have PHP 5.2.1.<br>> <a href="http://packages.ubuntu.com/feisty/web/php5">http://packages.ubuntu.com/feisty/web/php5</a><br>>
<br>> But, what about other distros? If they are on PHP4 or 5.1, then this will<br>> be a show stopper.<br><br>I'm not deprecating the existing mysql and pgsql drivers at this point. This is strictly a "if you're using a stable version of PHP 5, then you get this extra, faster option" feature.
</blockquote><div><br>Good. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Eventually I hope to deprecate the legacy database drivers and just use PDO with thin wrappers (for db_query_range() and such) for all database stuff, but that's not something we can even consider until 2008 at the earliest. Several web hosts already offer
5.2, though, as do some distros (Debian Etch, Ubuntu Feisty, etc.), so for those people the PDO option should offer a performance boost on prepared statements.</blockquote><div><br></div>the problem is that Red Hat and Fedora seem to be more common on hosts than
<br>the Debian/Ubuntu variants (which is my favorite).<br><br>As you said, if we are not relying on it solely, then why not include it for those who<br>can use it.<br></div>