On Wed, Sep 6, 2017 at 11:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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 what people need is the ability to force the behavior in either direction - either insist on a custom plan, or insist on a generic plan. The former is what you need if the plan stinks, and the latter is what you need if replanning is a waste of effort. I have seen both cases. The latter has been a bigger problem than the former, because the former can be hacked around in various ugly and inefficient ways, but if we're adding a knob I think it should have three settings. There is perhaps an argument for even more configurability, like altering the number of plan tries from 5 to some other value, but I'm not clear that there's any use case for values other than 0, 5, and +infinity. >> 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. What sort of funny behavior are you concerned about? It seems likely to me that in most cases the GUC will have the same value every time through, but if it doesn't, I'm not sure why we'd need to use the old value rather than the current one. Indeed, if the user changes the GUC from "force custom" to "force generic" and reruns the function, we want the new value to take effect, lest a POLA violation occur. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
