Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XEzwm-0000fZ-V3 for pgsql-sql@arkaria.postgresql.org; Wed, 06 Aug 2014 12:04:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XEzwl-0000Zb-Tq for pgsql-sql@arkaria.postgresql.org; Wed, 06 Aug 2014 12:03:59 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XEzwk-0000ZU-IS for pgsql-sql@postgresql.org; Wed, 06 Aug 2014 12:03:58 +0000 Received: from mail-pd0-x22a.google.com ([2607:f8b0:400e:c02::22a]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XEzwf-0002IK-V3 for pgsql-sql@postgresql.org; Wed, 06 Aug 2014 12:03:56 +0000 Received: by mail-pd0-f170.google.com with SMTP id g10so3219394pdj.1 for ; Wed, 06 Aug 2014 05:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=BkT9YJoyXR4jOADFw/paALawNllne2hOyDgn1KF4bYo=; b=ks3odxve+1QnheuPIjrMZxwBU0evUCCud4SWV4sjd4UZ49+/V44Sn1R7AN4zCrmR/i tZfTS5OJrN9cDxlnI+0NKhRPLt9vhvzhqpXkoQ48c0l79jus5IEN+JPT1Cx26ApW8w0p Pf0vmDRHcpIepxBuKWgfMJ68Bu/I60fVw7wScFJtxlR3TneZe0/hcZQtQobGpKWaJz7r yUrc/3Es9YHYWftH8qkcKl0ZRzjT0adSASCgGkLybBVKH803HPhmp4NR9/fs2h5dIW6u IxQgEXx4p+bkh67s4r0Kr6DEKG5Dkc0hnxBr8xohcKDv/nUBFAQVEdALR6TFDSik205r 4peg== X-Received: by 10.66.227.73 with SMTP id ry9mr11040808pac.18.1407326632405; Wed, 06 Aug 2014 05:03:52 -0700 (PDT) Received: from [192.168.1.100] ([73.162.177.114]) by mx.google.com with ESMTPSA id w10sm1100219pbt.17.2014.08.06.05.03.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Aug 2014 05:03:51 -0700 (PDT) Message-ID: <53E219A9.10806@gmail.com> Date: Wed, 06 Aug 2014 05:03:53 -0700 From: "John L. Poole" Reply-To: jlpoole56@gmail.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Re: function call References: <53E0D58E.9040502@aklaver.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070801050807070703010306" X-Pg-Spam-Score: -1.7 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org This is a multi-part message in MIME format. --------------070801050807070703010306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wouldn't this issue be an excellent candidate to create a test example and then log a bug with all the details so others can recreate the issue? It's very difficult to divine what the problem is unless you can provide a working example that demonstrates it. John On 8/6/2014 12:41 AM, Marcin Krawczyk wrote: > It's not ODBC, I've just tested with simple C# through the same odbc > source and the function takes 4 seconds as well. > > > regards > mk > > > 2014-08-05 15:01 GMT+02:00 Adrian Klaver >: > > On 08/05/2014 04:28 AM, Marcin Krawczyk wrote: > > Hi list, > > I have a SET returning function (defined as RETURNS TABLE), it > takes 2 > parameters and always returns one row with 3 columns. Now when > I run it > from pgAdmin it takes around 5 seconds but when I run it from the > application its around 3 minutes (same parameters of course). > It shows > up in the postgres' status server and odbc log right away so I > believe > the applications has nothing to do with it. Where should I > start looking ? > > > Just had another thought. > > I found in the past that ODBC logging can slow things down > considerably. > > What happens if you turn off the ODBC logging? > > > > > I'm running postgres 9.1 > > > regards > mk > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > --------------070801050807070703010306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Wouldn't this issue be an excellent candidate to create a test example and then log a bug with all the details so others can recreate the issue?  It's very difficult to divine what the problem is unless you can provide a working example that demonstrates it.

John
On 8/6/2014 12:41 AM, Marcin Krawczyk wrote:
It's not ODBC, I've just tested with simple C# through the same odbc source and the function takes 4 seconds as well.


regards
mk


2014-08-05 15:01 GMT+02:00 Adrian Klaver <adrian.klaver@aklaver.com>:
On 08/05/2014 04:28 AM, Marcin Krawczyk wrote:
Hi list,

I have a SET returning function (defined as RETURNS TABLE), it takes 2
parameters and always returns one row with 3 columns. Now when I run it
from pgAdmin it takes around 5 seconds but when I run it from the
application its around 3 minutes (same parameters of course). It shows
up in the postgres' status server and odbc log right away so I believe
the applications has nothing to do with it. Where should I start looking ?

Just had another thought.

I found in the past that ODBC logging can slow things down considerably.

What happens if you turn off the ODBC logging?




I'm running postgres 9.1


regards
mk


--
Adrian Klaver
adrian.klaver@aklaver.com



--------------070801050807070703010306--