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

Re: Prepared statements considered harmful

From: "zhou bo" <tate_zhou(at)hotmail(dot)com>
To: nagy(at)ecircle-ag(dot)com, peter_e(at)gmx(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prepared statements considered harmful
Date: 2006-08-31 13:05:31
Message-ID: BAY113-F1965616C48598990A3FED99C3F0@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
hello everyone , 

    i has been add to you guys' mail list by accident, i don't how to 
refuse to receive your mails, would you please help me to remove my mail 
address form mail group pgsql-hackers(at)postgresql(dot)org?

    i appreciatewhat you will do for me. (my mail address: 

thanks .

>From: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
>To: Peter Eisentraut <peter_e(at)gmx(dot)net>
>CC: postgres hackers <pgsql-hackers(at)postgresql(dot)org>
>Subject: Re: [HACKERS] Prepared statements considered harmful
>Date: Thu, 31 Aug 2006 14:52:05 +0200
>On Thu, 2006-08-31 at 14:32, Peter Eisentraut wrote:
> > Am Donnerstag, 31. August 2006 14:11 schrieb Csaba Nagy:
> > > How about "prepared" means really "prepared"... in the sense of 
> > > analyzed all sensible plans, and save a meta-plan which based on 
> > > statistics and parameter values chooses one of the considered (and
> > > cached) plans ?
> >
> > I don't think this could solve one particularly frequent problem which 
is that
> > pattern matching queries don't get along with prepared plans if the 
> > pattern isn't known at planning time.
>Why not ? I specifically said you would prepare a few sensible plans
>based on statistics/expected variations of the statistics, and parameter
>value ranges which would trigger different plans.
>So for the like query case you could save 2 plans, one for the indexable
>case, one for the not indexable case. Then at runtime you choose the
>proper one based on the pattern value. The meta-plan I mentioned would
>be a collection of plans with rules to choose the right one at run time
>based on parameter values and perhaps the current statistics.
>This of course would need a lot more preparation time than just prepare
>one plan, but that's why you want to do it upfront and then cache the
>results. A central plan repository mentioned in other posts would fit
>nicely here... and you could use prepared plans for non-parameterized
>queries too by simply considering the constants as parameters, to
>increase the chances for a prepared plan reuse - this of course for
>complex enough queries.
>---------------------------(end of broadcast)---------------------------
>TIP 6: explain analyze is your friend

In response to

pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2006-08-31 13:06:57
Subject: Re: Prepared statements considered harmful
Previous:From: Merlin MoncureDate: 2006-08-31 13:05:23
Subject: Re: Prepared statements considered harmful

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