| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Lukas Smith <smith(at)pooteeweet(dot)org> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Automatic function replanning |
| Date: | 2005-12-22 21:20:55 |
| Message-ID: | 20051222212055.GM72143@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 22, 2005 at 10:14:15PM +0100, Lukas Smith wrote:
> Ok, just so I understand this correctly. In the mentioned case the
> cardinality does not really change in regards to the table stats, its
> just thatI happen to use a value that has a different selectivity and
> therefore I may need a different plan. So I do not really see how this
> use case is handled with the above todo, nor do I really see how its
> handled with what Jim suggested earlier. The fact of the matter is that
> for this use case you need to use different query plans for the same
> prepared statements.
What I mentioned would allow for identifying query plans that this is
happening on. Doing something about it would be the next step after
that.
Can anyone think of something other than selectivity that would make a
stored query plan go bad based soley on the parameters being fed into it?
(In other words ignore the obvious cases of bad statistics or a DDL
change).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-12-22 21:20:57 | Re: Automatic function replanning |
| Previous Message | Jim C. Nasby | 2005-12-22 21:18:14 | Re: Automatic function replanning |