Re: Poor plan choice in prepared statement - Mailing list pgsql-performance

From Gregory Stark
Subject Re: Poor plan choice in prepared statement
Date
Msg-id 877i5hotv6.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Poor plan choice in prepared statement  (david@lang.hm)
List pgsql-performance
david@lang.hm writes:

> since there is not a pre-parsed interface for queries, it may make sense to
> setup a way to have the query pre-parsed, but not pre-planned for cases like
> this.

What would be more interesting would be to have plans that take into account
the outlier values and have alternative plans for those values.


One aspect that hasn't been discussed here is whether it's only certain
outlier arguments that cause Postgres to choose the poor plan for you or
whether it always chooses it for all the sets of arguments you actually use.

If it's the former then it's possible you're only being bitten if the first
time you prepare the query happens to have one of these outlier set of
parameters. I forget what version this went in but I think it was before 8.2
that Postgres started using the first set of arguments seen to plan the query.
This is usually an improvement over just guessing but if that first set is
unusual it could lead to strange results.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

pgsql-performance by date:

Previous
From: david@lang.hm
Date:
Subject: Re: Poor plan choice in prepared statement
Next
From: "Guillaume Smet"
Date:
Subject: Re: Poor plan choice in prepared statement