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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org