sql-performance-explained | Talk about Markus Winand book on SQL performance | SQL Database library

1. It depends.

When not using prepared statements, PostgreSQL plans a query every time anew, using parameters values. It is known as custom plan.

With prepared statements (and you're right, PL/pgSQL functions do use prepared statements) it's more complicated. PostgreSQL prepares the statement (parses its text and stores parse tree), but re-plans it each time it is executed. Custom plans are generated at least 5 times. After that the planner considers using a generic plan (i. e. parameter-value-independent) if it's cost is less than the average cost of custom plans generated so far.

Note, that cost of a plan is an estimation of the planner, not real I/O operations or CPU cycles.

So, the problem can occur, but you need some bad luck for that.

2. The approach you suggested will not work, because it doesn't change behavior of the function.

In general it is not so ugly for PostgreSQL not to use parameters (as it is for e. g. Oracle), because PostgreSQL doesn't have shared cache for plans. Prepared plans are stored in each backend's memory, so re-planning will not affect other sessions.

But as far as I know, currently there is no way to force planner to use custom plans (other than reconnect after 5 executions...).