Skip site navigation (1) Skip section navigation (2)

Re: Execution from java - slow

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Jayadevan M <Jayadevan(dot)Maymala(at)ibsplc(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Execution from java - slow
Date: 2012-08-28 07:11:16
Message-ID: CABOikdP1uTvULh59dhr-et6-5h-rA6sXYjc7s5P3sznBz_jR8w@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, Aug 27, 2012 at 6:07 PM, Jayadevan M
<Jayadevan(dot)Maymala(at)ibsplc(dot)com>wrote:

> Hello all,
>
> I have a plpgsql function that takes a few seconds (less than 5) when
> executed  from psql. The same function, when invoked from java via a
> prepared statement takes a few minutes. There are a few queries in the
> function. Out of these, the first query takes input parameters for
> filtering the data. It is this query which takes a long time when the
> procedure is invoked from java. To ensure that the query does use actual
> values (and not bind variables) for optimization, we used
>
> execute
> '
> select x.col_type_desc,x.acc_id,acc_svr from (.....
> '
> using d_from_date,d_to_date
>
> It did not help. Any suggestions? It is from_date and to_date on which
> data gets filtered. We are using the same values for filtering, when we
> execute it from java/psql
>
>
It looks highly unlikely that a function execution will take more time
through different client interfaces. May be you want to log the function
input parameters and see if they are coming different through these
interfaces (I think you can use RAISE NOTICE for that). I'm not sure but
client side encoding might also cause changes in the real values of the
date parameters you are passing (e.g mm/dd/yy vs dd/mm/yy). So that will be
worth checking as well.

Thanks,
Pavan

In response to

Responses

pgsql-performance by date

Next:From: Mathieu De ZutterDate: 2012-08-28 07:39:26
Subject: pg_trgm and slow bitmap index scan plan
Previous:From: Craig RingerDate: 2012-08-28 06:53:54
Subject: Re: Vacuum problems with 9.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group