Robert Haas <robertmh...@gmail.com> writes:
> I don't think we can just indefinitely continue to resist
> providing manual control over this behavior on the theory that some
> day we'll fix it.
That's fair enough. We need to have a discussion about exactly what
the knob does, which is distinct from the question of how you spell
the incantation for twiddling it. I'm dubious that a dumb "force a
custom plan" setting is going to solve all that many cases usefully.
> I think a GUC is a decent, though not perfect, mechanism for this.
> This problem isn't restricted to PL/pgsql; indeed, the cases I've seen
> have come via prepared queries, not PL/pgsql functions.
That's 100% correct, and is actually the best reason not to consider
a PRAGMA (or any other plpgsql-specific mechanism) as the incantation
spelling.
> I think it is in general unfortunate that we don't have a mechanism to
> change a GUC for the lifespan of one particular query, like this:
> LET custom_plan_tries = 0 IN SELECT ...
Hmm. I think the core problem here is that we're trying to control
the plancache, which is a pretty much behind-the-scenes mechanism.
Except in the case of an explicit PREPARE, you can't even see from
SQL that the cache is being used, or when it's used. So part of what
needs to be thought about, if we use the GUC approach, is when the
GUC's value is consulted. If we don't do anything special then
the GUC(s) would be consulted when retrieving plans from the cache,
and changes in their values from one retrieval to the next might
cause funny behavior. Maybe the relevant settings need to be captured
when the plancache entry is made ... not sure.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
