From: Tommy Pham on
<?php
  $dbconn = pg_connect("dbname=publisher") or die("Could not connect");

  if (!pg_connection_busy($dbconn)) {
      pg_send_query($dbconn, "select * from authors; select count(*)
from authors;");
  }

  $res1 = pg_get_result($dbconn);
  echo "First call to pg_get_result(): $res1\n";
  $rows1 = pg_num_rows($res1);
  echo "$res1 has $rows1 records\n\n";

  $res2 = pg_get_result($dbconn);
  echo "Second call to pg_get_result(): $res2\n";
  $rows2 = pg_num_rows($res2);
  echo "$res2 has $rows2 records\n";
?>

There's the code example from that same link. You may have executed
the queries asynchronously, but the process of the results are still
serial. Let's face it, all of our processing of queries are not a
simple echo. We iterate/loop through the results and display them in
the desired format. Having execute the query and the processing of
the result in threads/parallel, you get the real performance boost
which I've been trying to convey the concept of serial versus
parallel.
From: Peter Lind on
On 25 March 2010 23:23, Tommy Pham <tommyhp2(a)gmail.com> wrote:
>
> There's the code example from that same link.  You may have executed
> the queries asynchronously, but the process of the results are still
> serial.  Let's face it, all of our processing of queries are not a
> simple echo.  We iterate/loop through the results and display them in
> the desired format.  Having execute the query and the processing of
> the result in threads/parallel, you get the real performance boost
> which I've been trying to convey the concept of serial versus
> parallel.

Actually, you haven't mentioned the processing as part of what the
threads do until now. I see your point though: if you split that part
off, you might gain some performance, that would otherwise be hard to
get at.
I wonder though, if the performance is worth it in the tradeoff for
the maintenance nightmare it is when you split out content processing
between 10 different threads. I wouldn't personally touch it unless I
had no other option, but that's just my opinion.

Anyway, I don't think either of us will change point of view much at
this point - so we should probably just give the mailing list a rest
by now. Thanks for the posts, it's been interesting to read :)

> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
</hype>
From: Tommy Pham on
On Thu, Mar 25, 2010 at 3:35 PM, Peter Lind <peter.e.lind(a)gmail.com> wrote:
> On 25 March 2010 23:23, Tommy Pham <tommyhp2(a)gmail.com> wrote:
>>
>> There's the code example from that same link.  You may have executed
>> the queries asynchronously, but the process of the results are still
>> serial.  Let's face it, all of our processing of queries are not a
>> simple echo.  We iterate/loop through the results and display them in
>> the desired format.  Having execute the query and the processing of
>> the result in threads/parallel, you get the real performance boost
>> which I've been trying to convey the concept of serial versus
>> parallel.
>
> Actually, you haven't mentioned the processing as part of what the
> threads do until now. I see your point though: if you split that part
> off, you might gain some performance, that would otherwise be hard to
> get at.

Because in the past, when someone mention performance issues, the
replies come in with: is DB structure optimized, are queries
optimized, is the code optimized? For those in the field long enough
and have all that optimized and want additional performance boost,
what else are there? Thus, when I mentioned threads/parallel, I don't
mean execution of queries, but of everything in the entire app/project
where the gain is desired.

>  I wonder though, if the performance is worth it in the tradeoff for
> the maintenance nightmare it is when you split out content processing
> between 10 different threads. I wouldn't personally touch it unless I
> had no other option, but that's just my opinion.
>
> Anyway, I don't think either of us will change point of view much at
> this point - so we should probably just give the mailing list a rest
> by now. Thanks for the posts, it's been interesting to read :)
>

Agreed. :)
From: Per Jessen on
Peter Lind wrote:

> Anyway, I don't think either of us will change point of view much at
> this point - so we should probably just give the mailing list a rest
> by now. Thanks for the posts, it's been interesting to read :)

Most of it. +1


--=20
Per Jessen, Z=C3=BCrich (11.6=C2=B0C)