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


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to