| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bart Samwel <bart(at)samwel(dot)tk>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Avoiding bad prepared-statement plans. |
| Date: | 2010-02-16 14:31:44 |
| Message-ID: | 162867791002160631h7814785bo64d3e203fddb3ac1@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> Well using parameters will always have a better chance of producing a
> better plan but that's not the only factor people consider important.
> For a lot of users *predictability* is more important than absolute
> performance. If my web server could run 10% faster that might be nice
> but if it's capable of keeping up at its current speed it's not
> terribly important. But if it means it crashes once a day because some
> particular combination of parameters causes a bad plan to be used for
> a specific user that's a bad trade-off.
>
+1
Pavel
> --
> greg
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-02-16 14:36:32 | Re: Explain buffers display units. |
| Previous Message | Greg Stark | 2010-02-16 14:28:57 | Re: Avoiding bad prepared-statement plans. |