Thread: SRFs ... no performance penalty?

Folks,

I'm working on the demo session for our upcoming presentation at PHPCon.

As a side issue, we ended up comparing 3 versions of the same search screen:

1) All in PHP with views;
2) Using a function to build a query and count results but executing that
query directly and sorting, paging in PHP;
3) Using a Set Returning function to handle row-returning, sorting, and
paging.

All three methods were executing a series moderately complex query against a
medium-sized data set (only about 20,000 rows but it's on a laptop).  The
postgresql.conf was tuned like a webserver; e.g. low sort_mem, high
max_connections.

So far, on the average of several searches, we have:

1) 0.19687 seconds
2) 0.20667 seconds
3) 0.20594 seconds

In our tests, using any kind of PL/pgSQL function seems to carry a 0.01 second
penalty over using PHP to build the search query.   I'm not sure if this is
comparitive time for string-parsing or something else; the 0.01 seems to be
consistent regardless of scale.

The difference between using a PL/pgSQL function as a query-builder only (the
7.2.x method) and using SRFs was small enough not to be significant.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Mon, 2003-10-20 at 20:55, Josh Berkus wrote:
> Folks,
>
> I'm working on the demo session for our upcoming presentation at PHPCon.
>
> As a side issue, we ended up comparing 3 versions of the same search screen:
>
> 1) All in PHP with views;
> 2) Using a function to build a query and count results but executing that
> query directly and sorting, paging in PHP;
> 3) Using a Set Returning function to handle row-returning, sorting, and
> paging.
>
> All three methods were executing a series moderately complex query against a
> medium-sized data set (only about 20,000 rows but it's on a laptop).  The
> postgresql.conf was tuned like a webserver; e.g. low sort_mem, high
> max_connections.
>
> So far, on the average of several searches, we have:
>
> 1) 0.19687 seconds
> 2) 0.20667 seconds
> 3) 0.20594 seconds
>

Is this measuring time in the back-end or total time of script
execution?


> In our tests, using any kind of PL/pgSQL function seems to carry a 0.01 second
> penalty over using PHP to build the search query.   I'm not sure if this is
> comparitive time for string-parsing or something else; the 0.01 seems to be
> consistent regardless of scale.
>
> The difference between using a PL/pgSQL function as a query-builder only (the
> 7.2.x method) and using SRFs was small enough not to be significant.
>
> --
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert,

> > 1) 0.19687 seconds
> > 2) 0.20667 seconds
> > 3) 0.20594 seconds
>
> Is this measuring time in the back-end or total time of script
> execution?

Total time of execution, e.g. from clicking the "enter" button to displaying
the list of matches.  Any other comparison would be misleading.

--
Josh Berkus
Aglio Database Solutions
San Francisco