Bruce Momjian wrote:
> Also, is it possible to do an EXPLAIN prepare() with the libpq/wire
> protocol? I can't do PREPARE EXPLAIN, but I can do EXPLAIN EXECUTE.
> However, I don't see any way to inject EXPLAIN into the libpq/wire
> prepare case. Can you specify prepare(EXPLAIN SELECT)? (PREPARE
> EXPLAIN SELECT throws a syntax error.)
I am not sure what you mean:
EXPLAIN PREPARE to get EXPLAIN for PREPARE, or PREPARE ... FOR EXPLAIN
to get an EXPLAIN statement with parameters.
What should EXPLAIN PREPARE show that EXPLAIN SELECT wouldn't?
Why the need for EXPLAIN statements with parameters?
> Looking at how the code behaves, it seems custom plans that are _more_
> expensive (plus planning cost) than the generic plan switch to the
> generic plan after five executions, as now documented. Custom plans
> that are significantly _cheaper_ than the generic plan _never_ use the
> generic plan.
Yes, that's what the suggested documentation improvement says as well,
right?
> Updated patch attached.
Upon re-read, one tiny question:
! Prepared statements can optionally use generic plans rather than
! re-planning with each set of supplied <command>EXECUTE</command> values.
Maybe the "optionally" should be omitted, since the user has no choice.
It is true that there is a cursor option CURSOR_OPT_CUSTOM_PLAN, but that
cannot be used on the SQL level.
Yours,
Laurenz Albe
