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

Re: Poor plan choice in prepared statement

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, bricklen <bricklen(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Poor plan choice in prepared statement
Date: 2008-12-31 16:01:18
Message-ID: 20081231160118.GE3809@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-performance
Tom Lane escribió:
> Scott Carey <scott(at)richrelevance(dot)com> writes:
> > I have also had a case where one query would take a  couple hundred
> > ms to parse, but was fairly fast to plan and execute (1/3 the parse
> > cost) -- yet another case where a prepared statement that re-plans
> > each execution would be helpful.  At least you can prevent SQL
> > injection and cut the parse cost.  Its not all about the cost of
> > planning the query.
> 
> The point of a prepared statement IMHO is to do the planning only once.
> There's necessarily a tradeoff between that and having a plan that's
> perfectly adapted to specific parameter values.

I think it has been shown enough times that the performance drop caused
by a worse plan can be orders of magnitudes worse than what's gained by
producing the plan only once.  It does not seem a bad idea to provide a
way to carry out only the parse phase, and postpone planning until the
parameters have been received.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2009-01-01 13:44:50
Subject: Re: Poor plan choice in prepared statement
Previous:From: bricklenDate: 2008-12-31 15:11:17
Subject: Re: Poor plan choice in prepared statement

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