Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxUeM-0002hn-2t for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 08:58:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dxUeL-00005B-MA for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 08:58:29 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dxUeK-0008WL-P0 for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 08:58:28 +0000 Received: from mail-wr0-x22f.google.com ([2a00:1450:400c:c0c::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dxUeI-0002UM-6n for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 08:58:27 +0000 Received: by mail-wr0-x22f.google.com with SMTP id v109so1401667wrc.1 for ; Thu, 28 Sep 2017 01:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aPQ8VaK+JO3Cp4pJQrZknygxfbDKN3IamUhu6lghdwM=; b=LuiQwaDZeaCd0EdqhML/0R3qVKZHyrr6cT3t4C0H9UI2uQ3IeLBfhUSTRq45gslbm/ y0PkQV8+zT9cPNBuzQ/ZHHpQ52bLrz0KqurOzinaRbf4+QF2FcfnKgyMHXfELXZ3JQzb rUGysSyHtabT2I3SMYHlEsuvmTwV9XSYoZ1Pk9E+mr9nyphq6DmVdWOKxVCVHsNxkq4t dudphUJHG+uFW5Wu74jtFguyvi/V8a28V8MrkATgUBW2qbmdqLd4Tj+nfY2790nOJX6+ 2Da+uPKHfEDgtIFtMty5cQ8xtMbI+KESwcKOvfwsp4ZoUxb8Y0J5pMmKtLipGw6RmwbU Sr/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aPQ8VaK+JO3Cp4pJQrZknygxfbDKN3IamUhu6lghdwM=; b=guEM5Bv7OaVa6FTH2BKOptjyIL7i8Rq+LZuUj8fnG37wxFZNNWoLB/RVEFjICl04RX 9WOswPQRByydtqqs0V6RUDWiMNKzSI3cGje4mnnJW0GxYBH60h37kp59a1b3M77Dou3S sMZWFm/JerNNE9+4wnH6GP9qY+O6R+njn7HVKbtMQJue2F3Ks2TxB+0g3ZpBFXIS4wH+ j8KtaVz2rmk4V/7MkXTMMz65KQTbW/GiwNw2SlYWSqUXJBrWSnNemnBiObpT7Cjud0Z+ TlPqE9G5IOBOqraSARsBnsd0WwwkIOZ/1eslM2hHo3LF6xEIIwzU0HT/ynEg40WcrpPa E9gQ== X-Gm-Message-State: AMCzsaVQgBeModnqfOf5xFWQBJFEMIZrVy0oZiztU/hIwOOIDdQXvgcl siVZOhEaHWSeP5ac6118H4VrexvzGeMsaqv9uPY= X-Google-Smtp-Source: AOwi7QAhlTMwkZZ2lM5qVn49L9zrL2hIR/PR0V+Ez1fd1Eut3WZvIn0kLeAQcTWMCe4ubwWWffiniWJg7oNVZVE5tko= X-Received: by 10.25.228.148 with SMTP id x20mr1378784lfi.11.1506589104440; Thu, 28 Sep 2017 01:58:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.235.85 with HTTP; Thu, 28 Sep 2017 01:58:24 -0700 (PDT) In-Reply-To: References: From: Subramaniam C Date: Thu, 28 Sep 2017 14:28:24 +0530 Message-ID: Subject: Re: Slow query in JDBC To: Julien Rouhaud Cc: pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary="94eb2c0dc568648a61055a3c1c60" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --94eb2c0dc568648a61055a3c1c60 Content-Type: text/plain; charset="UTF-8" I configured cursor_tuple_fraction to 1 but still I am facing the same issue. Please help. On Thu, Sep 28, 2017 at 2:18 PM, Julien Rouhaud wrote: > On Thu, Sep 28, 2017 at 10:19 AM, Subramaniam C > wrote: > > Hi > > > > When I try to execute the query from sql command line then that query is > > taking only around 1 sec. But when I execute the query using JDBC(Java) > > using preparedStatement then the same query is taking around 10 secs. > > > > Can you please let us know the reason and how to fix this issue? > > > I think jdbc always uses cursor, which can be problematic with default > configuration, because postgres will try to generate plans that > returns fast the first rows but not all the rows . Can you try to > configure cursor_tuple_fraction to 1 and see if that fixes your issue? > --94eb2c0dc568648a61055a3c1c60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I configured=C2=A0cursor_tuple_fraction to 1 but still I am facing the same issue.
Please help.<= /div>

On Thu= , Sep 28, 2017 at 2:18 PM, Julien Rouhaud <rjuju123@gmail.com> wrote:
On Thu, Sep 2= 8, 2017 at 10:19 AM, Subramaniam C
<subramaniam31784@gmail.co= m> wrote:
> Hi
>
> When I try to execute the query from sql command line then that query = is
> taking only around 1 sec. But when I execute the query using JDBC(Java= )
> using preparedStatement then the same query is taking around 10 secs.<= br> >
> Can you please let us know the reason and how to fix this issue?


I think jdbc always uses cursor, which can be problematic with defau= lt
configuration, because postgres will try to generate plans that
returns fast the first rows but not all the rows .=C2=A0 Can you try to
configure cursor_tuple_fraction to 1 and see if that fixes your issue?

--94eb2c0dc568648a61055a3c1c60--