Thread: LANGUAGE sql functions don't use the custom plan logic
Hi, I recently was forcfully reminded that sql functions don't use the plancache.c infrastructure. I was sort of aware of that, but I didn't think far enough ahead that that also implies we'll not use custom plans for statements with parameters when it'd be helpful. That's imo quite the trap. Should we document it somewhere? Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > I recently was forcfully reminded that sql functions don't use the > plancache.c infrastructure. I was sort of aware of that, but I didn't > think far enough ahead that that also implies we'll not use custom plans > for statements with parameters when it'd be helpful. There's a whole lot of ways in which the current implementation of SQL-language functions leaves things to be desired. What did you run into exactly? regards, tom lane
On 2015-07-10 09:52:30 -0400, Tom Lane wrote: > There's a whole lot of ways in which the current implementation of > SQL-language functions leaves things to be desired. Yea. > What did you run into exactly? A generic plan was used on a partitioned table. Normally the function could be inlined so that wasn't noticeable, but in one case it wasn't... It's confusing if all invocations of the same function are reasonably fast, but one, with the numerically same values passed down, isn't. Andres