[PERFORM] plpgsql vs. SQL performance (again)
About a month ago I asked the general list about plpgsql functions that occasionally significantly underperform their straight SQL equivalents. Tom noted that a different query plan was almost certainly being chosen by the plpgsql function: http://archives.postgresql.org/pgsql-general/2003-05/msg00966.php http://archives.postgresql.org/pgsql-general/2003-05/msg00998.php Tom suggested checking for sloppy datatype declarations in the plpgsql functions. Double-checked, a-ok. Tom also suggested that indexscans might not get picked by the plpgsql function if I have some very skewed statistics. Is there a way to verify the plpgsql function's planner choices? My casual observations are that this problem occurs with aggregates, and that the big performance hit is not consistent. I'd like advice on more formal troubleshooting. I can provide examples (my latest problem function is currently taking over 4 seconds vs. .04 seconds for its straight SQL equivalent), table schema, explain output for the straight SQL, etc., if anyone cares to work through this with me. thanks, michael ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Moving postgresql.conf tunables into 2003...
On Sun, 6 Jul 2003, Matthew Nuzum wrote: At the very least, if there is good documentation for these parameters, maybe the conf file should provide a link to this info. I believe that is what Josh is proposing: http://archives.postgresql.org/pgsql-performance/2003-07/msg00102.php [Apache httpd] uses a three phase (if not more) documentation level. The .conf file contains detailed instructions in an easy to read and not-to-jargon-ish structure. The docs provide detailed tutorials and papers that expand on configuration params in an easy to read format. Both of these refer to the thorough reference manual that breaks each possible option down into it's nitty gritty details so that a user can get more information if they so desire. I agree that Apache's approach is primo. Often the .conf comments are enough to jog my memory about a directive I haven't used for a while. Or the comments are enough to let me know I don't need a directive, or that I need to go to the manual and read more. I appreciate that. michael ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
