Re: Retrieving result of COUNT(*) with PHP

Pardon the label on the last run, it should be seconds.

On 3/28/07, Gavin M. Roy <gmr(at)ehpg(dot)net> wrote:
>
> For large volumes of data, this will be slower. PostgreSQL has to do more
> work on select * FROM table than select count(*) from table...
>
> I wrote a little test script to explain this:
>
> Run 1, with numRows: 60348 rows returned, duration of 0.379431 seconds
> Run 1, with count: 60348 count returned, duration of 0.061221 seconds
>
> Run 2, with numRows: 60348 rows returned, duration of 0.323478 seconds
> Run 2, with count: 60348 count returned, duration of 0.110275 seconds
>
> Run 3, with numRows: 60348 rows returned, duration of 0.379429 miliseconds
> Run 3, with count: 60348 count returned, duration of 0.061281 miliseconds
>
> Source Code:
>
> // pg_NumRows code
> $start = microtime(true);
> $result = pg_Exec($conn, "SELECT i_poemid FROM poetry;");
> $rows = pg_NumRows($result);
> $end = microtime(true) - $start;
>
> // Count Code
> $start = microtime(true);
> $result = pg_Exec($conn, "SELECT count(*) FROM poetry;");
> $data = pg_Fetch_Object($result, 0);
> $send = microtime(true) - $start;
>
> In this scenario, i_poemid is the primary key of a table with 60k rows.
>
> Regards,
>
> Gavin
>
>
>
>
> On 3/28/07, Valentín Orfila <valentinorfila(at)gmail(dot)com> wrote:
> >
> >
> > Where people this the way I do, count (*) could be slower
> >
> > <?
> > $sql = "select * from TableName";
> > $count = pg_query($sql);
> > $count = pg_num_rows($count);
> > ?>
> > <td ><?=$count?></td>
> >
> > I thing that's enough :)
> >
> > 2007/3/28, Mihail Mihailov <Mihail(dot)Mihailov(at)uta(dot)fi >:
> > >
> > > Hi,
> > >
> > > actually, I don't think you need pg_fetch_all.
> > > I use pg_fetch_row for the purpose. What you get with the SELECT
> > > clause is one row.
> > >
> > > E.g. like this:
> > > $res = pg_fetch_row(pg_query("SELECT COUNT(*) AS result_count FROM
> > > etc. WHERE etc.")); //Not a very good style :-), one should check if
> > > the query runs
> > > $count = $res[0];
> > >
> > > Another way to calculate number of rows in the result is to use
> > > pg_num_rows function.
> > > $res = pg_query("SELECT COUNT(*) AS result_count FROM etc. WHERE
> > > etc.");
> > > $count = pg_num_rows($res);
> > >
> > > Enjoy!
> > >
> > > Mihail
> > >
> > >
> > >
> > > Quoting Lynna Landstreet <lynna(at)spidersilk(dot)net >:
> > >
> > > > Hi there,
> > > >
> > > > I'm trying to use a SELECT COUNT(*) to count how many results would
> > > be
> > > > retrieved from a particular query (as part of the process of
> > > paginating
> > > > search results).
> > > >
> > > > But I'm having trouble figuring out how to retrieve the result of
> > > the count
> > > > in PHP. The result on its own is a resource rather than a specific
> > > value,
> > > > but when I try to retrieve the result via pg_fetch_result, some kind
> > > of
> > > > weird math error happens and I get a huge number that bears no
> > > resemblance
> > > > to the number of results the query actually gets when it runs
> > > (1,714,608 for
> > > > a query that in actuality produces three results).
> > > >
> > > > I tried using an AS clause (SELECT COUNT(*) AS result_count FROM
> > > etc. WHERE
> > > > etc.) to give the result a name, but that didn't help, and when I
> > > tried
> > > > using pg_fetch_all on the result to see exactly what it was
> > > retrieving, I
> > > > got this:
> > > >
> > > > Array
> > > > (
> > > > [0] => Array
> > > > (
> > > > [result_count] => 1714608
> > > > )
> > > >
> > > > )
> > > >
> > > > Again with the weird number. And yet, if I run the exact same query
> > > in the
> > > > SQL window of phpPgAdmin, I get the proper result count (3 in this
> > > > instance).
> > > >
> > > > Does anyone know what's going on here? Can I just not use SELECT
> > > COUNT(*)
> > > > with PHP at all?
> > > >
> > > > I originally had the script running the actual query and then
> > > counting the
> > > > results, and then running it again with LIMIT and OFFSET to get one
> > > page's
> > > > worth of results, but it seemed wasteful to do it that way, so I was
> > > trying
> > > > to do it more efficiently... :-/
> > > >
> > > > Thanks,
> > > >
> > > > Lynna
> > > >
> > > > --
> > > > Spider Silk Design - http://www.spidersilk.net
> > > > 509 St Clair W Box 73576, Toronto ON Canada M6C 1C0
> > > > Tel 416.651.2899 - Toll Free 1.866.651.2899 - Cell 416.873.9289
> > > >
> > > > ---------------------------(end of
> > > broadcast)---------------------------
> > > > TIP 2: Don't 'kill -9' the postmaster
> > > >
> > >
> > >
> > > ---------------------------(end of
> > > broadcast)---------------------------
> > > TIP 9: In versions below 8.0, the planner will ignore your desire to
> > > choose an index scan if your joining column's datatypes do not
> > > match
> > >
> >
> >
> >
> > --
> > ***************************************************************************
> >
> > Ministerio de Planificación y Desarrollo de la República Bolivariana de
> > Venezuela
> > Dirección de Planes de Personal
> >
> > José Valentín Orfila Briceño
> > Programador II
> >
> > Teléfonos: Celular: (0416) 4131418
> >
> > E-mail: valentinorfila(at)gmail(dot)com
> > valentinorfila(at)hotmail(dot)com
> > josevalentinorfila(at)yahoo(dot)com
> >
> > Messenger: valentinorfila(at)hotmail(dot)com
> >
> > Skype: valentinorfila
> > valentinorfila(at)gmail(dot)com
> > ***************************************************************************
> >
>
>
>