From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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:28:57 |
Message-ID: | 407d949e1002160628v14966092iea1bf26e34039344@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 15, 2010 at 7:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> 1. Why do we only do bind-level planning for anonymous wire-level queries?
>
> 2. I realize we did anonymous-only because that was the only way we had
> in the protocol to _signal_ bind-time planning, but didn't we think of
> this when we were implementing the wire-level protocol?
Is there any other difference between anonymous and non-anonymous
queries? If this is the only major difference do we need to separate
them? Is there any particular reason a driver would need two prepared
queries if they're both just going to be planned at execution time?
Incidentally, can you have two active anonymous portals at the same time?
> 4. Why don't we just always do planning at first bind time? When is
> that worse than using generic values?
>
> 6. When do our generic columns costs significantly worse than having
> specific constants? I assume unique columns are fine with generic
> constants.
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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-02-16 14:31:44 | Re: Avoiding bad prepared-statement plans. |
Previous Message | Greg Stark | 2010-02-16 14:22:00 | Re: Avoiding bad prepared-statement plans. |