Dear Alvarao, would you please so kind explaining me your opinion in details.
thanks, -- Csaba -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alvaro Herrera Sent: Thursday, December 23, 2004 3:58 PM To: Együd Csaba (Freemail) Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Very slow stored proc On Thu, Dec 23, 2004 at 10:51:46AM +0100, Együd Csaba (Freemail) wrote: Hi, > I've got it. Not the date handling is slow but the string handling. > Eliminating the huge string buffer and running all the inserts row by > row, the overall running time is 12 sec. > So as a conclusion never use large strings in plpgsql functions. I wonder why you are creating a table at all, when you could probably use a SRF instead in the queries where you are using such table. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "La tristeza es un muro entre dos jardines" (Khalil Gibran) ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 2004.12.22. -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 2004.12.22. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 2004.12.22. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.298 / Virus Database: 265.6.4 - Release Date: 2004.12.22. ---------------------------(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
