<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; Which distro?<br>&gt;<br>&gt; I use Ubuntu 6.10 and if you install PHP 5, 5.1.6 is the default you get.
<br>&gt; This makes<br>&gt; it harder to use 5.2 (custom compile, ...etc.)<br>&gt;<br>&gt; If you have working code, I can verify whether I have the same problem or<br>&gt; not on my test server.<br><br>I also run Ubuntu Edgy (
6.10), which is how I ran into this problem.&nbsp;&nbsp;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.&nbsp;&nbsp;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&nbsp; 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;">&gt; My concern here is that all db_num_rows() cases become two queries for<br>
&gt; people using MySQL (the vast majority) as well as PostgreSQL (it has<br>&gt; pg_num_rows()).<br><br>Not all, actually.&nbsp;&nbsp;At least one (in sess_write()) really should have been a count query in the first place as it&#39;s never iterated.&nbsp;&nbsp;I&#39;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.&nbsp;&nbsp;I don&#39;t think I&#39;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;">
&gt; If these are index only queries, then it may not be a big deal, but<br>&gt; anything more (which we have a lot of), would incur a significant performance penalty.<br>&gt; It also affects large sites using InnoDB which is notorious for very slow SELECT
<br>&gt; COUNT(*).<br>&gt;<br>&gt; See a benchmark here:<br>&gt;<br>&gt; <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&#39;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?&nbsp;&nbsp;It still has all the WHERE-ing to do.&nbsp;&nbsp;More specifically, MyISAM is a special case where count(*) is faster than it otherwise would be in any other situation.&nbsp;&nbsp;It&#39;s not that InnoDB is slow, it&#39;s that MyISAM is fast. :-)
</blockquote><div><br>But at present,&nbsp; 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&#39;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;">&gt; Not sure what else can be done here. Is there a way to sneek in a pass
<br>&gt; thru<br>&gt; function<br>&gt; (mysql_num_rows() in this case) like ODBC for example allows?<br><br>I&#39;m not sure what ODBC does.&nbsp;&nbsp;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&#39;m pretty sure one can&#39;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;">
&gt; Option D) : File a feature request against PDO to include a numRows()<br>&gt; method,<br>&gt; but that is not a quick solution.<br><br>That&#39;s the same as C for the forseeable future.&nbsp;&nbsp;Such an addition wouldn&#39;t be added until at least PHP 
5.3, I imagine, which is who knows when.&nbsp;&nbsp;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&#39;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;">&gt; I am hoping I can get this into Drupal 6, but time will tell if I can get
<br>&gt; it ready in time.<br>&gt;<br>&gt;<br>&gt; Ubuntu Feisty (due later in April) will have PHP 5.2.1.<br>&gt; <a href="http://packages.ubuntu.com/feisty/web/php5">http://packages.ubuntu.com/feisty/web/php5</a><br>&gt;
<br>&gt; But, what about other distros? If they are on PHP4 or 5.1, then this will<br>&gt; be a show stopper.<br><br>I&#39;m not deprecating the existing mysql and pgsql drivers at this point.&nbsp;&nbsp;This is strictly a &quot;if you&#39;re using a stable version of PHP 5, then you get this extra, faster option&quot; feature.&nbsp;&nbsp;
</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&#39;s not something we can even consider until 2008 at the earliest.&nbsp;&nbsp;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>