Re: Optimizing prepared statements

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimizing prepared statements
Date: 2006-09-04 05:23:19
Message-ID: 15561.203.121.164.162.1157347399.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, September 4, 2006 03:56, Gregory Stark wrote:

> Thanks, that cleared things up enormously. I'm trying to figure how it
> would
> react to some of the queries I've written in the past. In particular I'm
> thinking of queries like
>
> WHERE (? OR category = ?)
> AND (? OR cost < ?)
> AND (? OR description like ?||'%')
>
> Where I then pass flags in from the application to indicate which search
> constraints to apply. If it notices that most searches are for a
> particular
> set of constraints it would be able to cache plans with the unused
> constraints
> removed.

Right. That's pretty much the problem as Peter originally described it, I
think.

> It would not however be able to notice that the last parameter never
> contains a % and therefore can use an index scan.

If I understand you correctly, then no. If the algorithm sees highly
variable values for that last parameter, it will never decide to assume
that that parameter will never contain '%'--and I'm not sure how that
could be done safely.

I do see two glimmers of hope, however:

1. If that last parameter is usually some specific value, then you'll
probably end up using specialized plans with that specific value in the
parameter's place. If that value is a string without wildcards, you can
use your index on description (assuming you have one). If it's '%' or
null, the optimizer can decide to ignore the "like" clause. It's only
when the scheme finds that it cannot predict what the parameter's value is
going to be that you get the generic, poorly-performing code.

2. Once we have a predictor, and assuming it works, it could be tied in
with the planner a bit more. As I believe Tom said, the planner can't
afford to chase down lots of scenarios just in case they ever happen. But
when a parameter is used only for simple matches or inserts on non-indexed
columns, for example, the planner might find in the course of its normal
activities that there's nothing useful it can do with that parameter and
deliver this information with its plan, so that the predictor can ignore
the parameter.

> I'm also wondering how this interacts with plan stability. Obviously the
> direct effect is to throw out any chance of it. But in the long run they
> may be two complementary sides of the same thing.

Well, it'll cause some plans to be re-generated, surely. But the
impression I've gotten from the discussion so far is some that plans were
getting too old anyway.

Jeroen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Kahwe Smith 2006-09-04 05:36:54 Re: Getting a move on for 8.2 beta
Previous Message Tom Lane 2006-09-04 04:12:39 Re: [PATCHES] possible ecpg vpath build error