On Mon, 1 Mar 2010, Rainer Pruy wrote:
It is a Java app, using jdbc, but through a proprietary persistence
framework. I'm just busy evaluating the effects on the app of
prohibiting prepared statements via jdbc. If this is not worthwhile, I'm
bound to some expensive reorganizations, sigh.
Hi all,
I'm quite puzzled by the following observation.
The behaviour is observed on a production system (Linux, PG 8.3.5)
and also on a test system (NetBSD 5.0.2, PG 8.4.2).
Normally the following Query behaves well:
select c.*, h.*
from Context c, Context_Hierarchy h
where c.Idx =
Rainer Pruy rainer.p...@acrys.com writes:
Normally the following Query behaves well:
select c.*, h.*
from Context c, Context_Hierarchy h
where c.Idx = h.ContextIdx and c.ContextId='testID' and
h.HierarchyName='InsuranceHierarchy' and h.ParentIdx=49292395
;
Thanks for the hint.
I should have been considering that in the first place.
(But the obvious is easily left unrecognised..)
The prepared statement gives:
QUERY
PLAN
Rainer Pruy rainer.p...@acrys.com writes:
The prepared statement gives:
...
And that is quite a bad plan given the current distribution of values.
Yeah. The planner really needs to know the actual parameter values in
order to pick the best plan for this case.
One thing that you might be able
I'm already at it
It is a Java app, using jdbc, but through a proprietary persistence framework.
I'm just busy evaluating the effects on the app of prohibiting prepared
statements via jdbc.
If this is not worthwhile, I'm bound to some expensive reorganizations, sigh.
Nevertheless,
thanks for
Rainer Pruy wrote:
Thanks for the hint.
I should have been considering that in the first place.
(But the obvious is easily left unrecognised..)
The prepared statement gives:
QUERY
PLAN
