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