> Another technique that we could play with is to have the > AlternativeSubPlans node track the actual number of calls it gets, > and switch from the "retail" implementation to the "hashed" > implementation if that exceeds a threshold. This'd provide some > robustness in the face of bad estimates, although of course it's > not optimal compared to having made the right choice to start with.
Ideally you'd want to set that threshold dynamically. If you expect x calls and midway through execution notice that you're already up to 2x calls, the right thing to do depends a lot on whether you're 1% done or 99% done. Logic of this type also opens a bit of a can of worms, in that there are probably many other situations in which it's possible to notice that your estimates are off and shift gears in mid-query, but how much are you willing to slow down the queries where there isn't a problem to speed up the ones where there is? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
