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

Re: Avoiding bad prepared-statement plans.

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-09 12:59:15
Message-ID: 4B715C23.30101@gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeroen Vermeulen wrote:
> I've been discussing this with Josh, Heikki, and Peter E. over the 
> past few weeks.
Is this searchable in the archives? I'm interested in ideas discussed.
> If a prepared statement takes parameters, and the generic plan has a 
> high projected cost, re-plan each EXECUTE individually with all its 
> parameter values bound.  It may or may not help, but unless the 
> planner is vastly over-pessimistic, re-planning isn't going to 
> dominate execution time for these cases anyway.
This sounds like a really nice to have feature. Maybe it'd also be 
possible to skip replanning between executes if the current bound values 
are 'indexwise-equivalent' to the values used at previous planning, i.e. 
nothing in the statistics indicates that execution cost would be (much) 
different. Are there more ways to cut down on planning time? Obviously 
some plannedstatement/plannerinfo structures could be kept, but maybe 
it'd also be possible to plan only that part of the join tree where the 
params are used in a scan/join qual.

regards,
Yeb Havinga


In response to

Responses

pgsql-hackers by date

Next:From: Tollef Fog HeenDate: 2010-02-09 13:03:28
Subject: TCP keepalive support for libpq
Previous:From: Magnus HaganderDate: 2010-02-09 12:52:56
Subject: Re: buildfarm breakage

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