Re: [PERFORM] SRFs ... no performance penalty?
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
Re: [PERFORM] SRFs ... no performance penalty?
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PERFORM] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
