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

Re: Trouble with plan statistics for behaviour for query.

From: Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>
To: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
Cc: Trevor Campbell <tcampbell(at)atlassian(dot)com>, Craig James <cjames(at)emolecules(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Trouble with plan statistics for behaviour for query.
Date: 2012-06-01 15:38:10
Message-ID: CAOtHd0Bh+LxwQy70wfr9khrKGbz+umZBQDXYOnLLee4ZJ9e9Pw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performance
> If I am correct, JDBC uses named portal only on the 5th time you use
> PreparedStatement (configurable). Before it uses unnamed thing that should
> work as if you did embed the value.

If this is due to the difference in parameter type information, this
doesn't have anything to do with named portals.

My guess is that the driver has one idea about parameter types (based
on either the specific setTypeFoo call or the Java type of the
parameter passed to setObject), and the server another (based on the
type information of the CHANGEGROUP.ISSUEID column). Actually, I'm
rather surprised to see 'real' there: if you're using setObject with a
Long, I would imagine that turns into a bigint (which I believe the
server knows how to coerce to numeric). Can you show us your JDBC
code?

In response to

Responses

pgsql-performance by date

Next:From: Chris RimmerDate: 2012-06-01 15:41:53
Subject: Re: Select from sequence in slow query log
Previous:From: Tom LaneDate: 2012-06-01 15:15:09
Subject: Re: does the query planner consider work_mem?

pgsql-general by date

Next:From: utsavDate: 2012-06-01 15:48:03
Subject: TYPE TABLE OF NUMBER
Previous:From: Bryan MontgomeryDate: 2012-06-01 15:28:17
Subject: Question: How do you manage version control?

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