pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: David Kerr <dmk@mr-paradox.net>
To: Craig Ringer <craig@postnewspapers.com.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: Optimizer + bind variables
Date: Tue, 3 Nov 2009 15:52:46 -0800
Message-ID: <20091103235245.GA77360@mr-paradox.net> (raw)
In-Reply-To: <4AF0C014.4090000@postnewspapers.com.au>
References: <20091103174729.GA55736@mr-paradox.net>
	<4AF0C014.4090000@postnewspapers.com.au>

On Wed, Nov 04, 2009 at 07:43:16AM +0800, Craig Ringer wrote:
- David Kerr wrote:
- > Does/is it possible for the PG optimizer come up with differnet plans when 
- > you're using bind variables vs when you send static values?
- 
- Yes, if the bind variable form causes your DB access driver to use a
- server-side prepared statement. Pg can't use its statistics to improve
- its query planning if it doesn't have a value for a parameter when it's
- building the query plan.

hmm, that's a little unclear to me.

let's assume that the application is using prepare:

Assuming the database hasn't changed, would:
PREPARE bla1 as SELECT * from users where username = '$1';
explain execute bla1

give the same output as
explain select * from users where username = 'dave';

?

- Whether a server-side prepared statement is used or not depends on how
- you're connecting to the database - ie your DB access driver and
- version. If you're using JDBC, I *think* the JDBC driver does parameter
- placement client-side unless you're using a JDBC prepared statement and
- the JDBC prepared statement is re-used several times, at which point it
- sets up a server-side prepared statement. AFAIK otherwise it uses
- client-side (or Pg protocol level) parameter placement.
that's interesting, i'll need to find out which mine are using, probably
a mix of both.

- > if it's possible for the plan to be different how can i generate an
- > xplan for the bind version?
- 
- xplan = explain? If so:
yeah, sorry.

- Use PREPARE to prepare a statement with the params, then use:
- 
- EXPLAIN EXECUTE prepared_statement_name(params);
- 
- eg:
- 
- x=> PREPARE blah AS SELECT * FROM generate_series(1,100);
- PREPARE
- x=> EXPLAIN EXECUTE blah;
-                                QUERY PLAN
- ------------------------------------------------------------------------
-  Function Scan on generate_series  (cost=0.00..12.50 rows=1000 width=4)
- (1 row)

great thanks!

Dave



view thread (6+ messages)  latest in thread

Message-ID: <20091103235245.GA77360@mr-paradox.net>
Permalink:  ../20091103235245.GA77360@mr-paradox.net/
Also on:    postgresql.org/message-id/20091103235245.GA77360@mr-paradox.net

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: dmk@mr-paradox.net, craig@postnewspapers.com.au
  Subject: Re: Optimizer + bind variables
  In-Reply-To: <20091103235245.GA77360@mr-paradox.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox