Greg Stark <gsstark@mit.edu> writes:
> That's not true all the time, but I know 90% of my case statements are of this
> form. In some ideal world postgres would recognize this form and handle it
> specially using some kind of quick hash table lookup.
> I don't see how to reconcile that with postgres's extensible types though. I
> guess if postgres can see that every arm of the CASE is a '=' expression one
> side of which is a constant expression and all of the same type then it could
> use the same operators that the hash index code uses? That seems like it would
> be a lot of work though.
Yeah, trying to hash it is more work than I feel like doing. However I
think it would be a good idea to avoid multiple evaluations of the CASE
test expression, both for speed and to respect the principle of least
surprise. If the test expression is volatile, our present behavior is
unlikely to make the user happy.
The idea I was toying with is to generate, not "x = y" with repeated
copies of x, but "placeholder = y" where placeholder is a dummy
expression tree node. Then at runtime, the CASE code would evaluate the
test expression once and save it into the econtext so the dummy node(s)
could regurgitate that value. We already have exactly such a mechanism
in place to handle the VALUE keyword for domain check constraints;
it'd be easy to duplicate it for CASE.
regards, tom lane
