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

Re: Avoiding bad prepared-statement plans.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-11 03:12:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Kris Jurka wrote:
> The JDBC driver has two methods of disabling permanently planned prepared 
> statements:
> 1) Use the version two frontend/backend protocol via adding 
> protocolVersion=2 to your URL.  This interpolates all parameters into 
> the query on the client side.
> 2) Execute PreparedStatements using the unnamed statement rather than a 
> named statement via adding prepareThreshold=0 to your URL.  A named 
> statement is expected to be re-used for later execution and ignores the 
> passed parameters for planning purposes.  An unnamed statement may be 
> re-used, but it doesn't expect to be.  The unnamed statement uses the 
> passed parameters for planning purposes, but still cannot make certain 
> optimatizations based on the parameter values because it may be 
> re-executed again later with different parameters.  For example a LIKE 
> query with a parameter value of 'ABC%' cannot be transformed into range 
> query because the next execution may use a different parameter value for 
> which the transform is not valid.  By default the driver switches to using 
> a named statement after the same PreparedStatement object is executed five 
> times.

Can someone explain to me why we only do "delayed binding" for unnamed
prepared queries?  Why do we not allow this option for named protocol
prepared queries and SQL prepared queries?

Here is what our documentation has in the protocols section:

    The unnamed prepared statement is likewise planned during Parse processing
    if the Parse message defines no parameters.  But if there are parameters,
    query planning occurs during Bind processing instead.  This allows the
    planner to make use of the actual values of the parameters provided in
    the Bind message when planning the query.

and here is someone who is having problems with the generic plans we

Can we not document this better?

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-11 03:15:01
Subject: Re: Avoiding bad prepared-statement plans.
Previous:From: Robert HaasDate: 2010-02-11 03:02:12
Subject: Re: [PATCH] Output configuration status after ./configure run.

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