Re: JDBC, prepared queries, and partitioning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL - JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC, prepared queries, and partitioning
Date: 2008-02-13 20:47:34
Message-ID: 23221.1202935654@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2008-02-13 at 13:51 -0500, Kris Jurka wrote:
>> Using protocol version 2 will not prepare queries so constraint exclusion
>> can be used. Just append protocolVersion=2 to your URL.

> What about the prepare threshold?

Won't help; the problem is that the planner will never consider a Param
value as a true constant. So if you're trying to use out-of-line params
to avoid quoting/escaping/SQL-injection-risk issues, you're shut out of
constraint exclusion, as well as some other cases such as LIKE
optimization.

We could imagine having a different operating mode where a generated
plan is only used once and so the Param values can be taken as true
constants.

I suppose this could be implemented with a GUC variable rather than an
explicit protocol change, but I'm not sure if that'd be a good idea or
not. It's not entirely clear to me which layers on the client side need
to be aware of such behavior.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Simon Riggs 2008-02-13 20:56:21 Re: JDBC, prepared queries, and partitioning
Previous Message Kris Jurka 2008-02-13 20:43:46 Re: JDBC, prepared queries, and partitioning