Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 9F2151FBF224 for ; Tue, 27 Dec 2011 06:52:27 -0400 (AST) Received: from sam.nabble.com ([216.139.236.26]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RfUdu-0000C4-RT for pgsql-performance@postgresql.org; Tue, 27 Dec 2011 10:52:27 +0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RfUdh-0007iC-ON for pgsql-performance@postgresql.org; Tue, 27 Dec 2011 02:52:13 -0800 Date: Tue, 27 Dec 2011 02:52:13 -0800 (PST) From: MirrorX To: pgsql-performance@postgresql.org Message-ID: <1324983133749-5102940.post@n5.nabble.com> Subject: parse - bind take more time than execute MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: 0.9 (/) X-Archive-Number: 201112/168 X-Sequence-Number: 45967 there are some performance issues on a server and by searching in the logs i noticed that the phases of parse and bind take considerably more time than execute for most of the queries. i guess that the right thing to do in this case is to use functions or prepare statements but in any case, what could be the cause of this? information about the server-> -CentOS 5.6 -4-cores -12GB ram shared_buffers: 1 GB temp_buffers = 100MB work_mem : 30 MB maintenance_mem: 512 MB database_size: 1,5 GB archive_mode is ON vacuum/analyze (vacuum_scale_factor 0.1, analyze 0.05) this behaviour is not related with checkpoints on the database (as indicated by the logs, i dont see this latency when a checkpoint occurs, i see it most of the time) so my question is the following; what can cause the bind/parse phases to take so much longer than the execute? if you need any more info the server i ll be glad to provide it. thank you in advance for your advice -- View this message in context: http://postgresql.1045698.n5.nabble.com/parse-bind-take-more-time-than-execute-tp5102940p5102940.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com.