> While hooks are generally not installed by default, I would advise > against marking the hooks as unlikely, as that would unfairly penalize > the performance of extensions that do utilise this hook (or hooks in > general when applied to all hooks).
In general, we have a policy of using likely/unlikely very sparingly, and only in demonstrably hot code paths. This hook call certainly doesn't qualify as hot.
Having said that ... something I've been wondering about is how to teach the compiler that error paths are unlikely. Doing this across-the-board wouldn't be "sparingly", but I think surely it'd result in better code quality on average. This'd be easy enough to do in Assert:
#define Assert(condition) \ do { \ - if (!(condition)) \ + if (unlikely(!(condition))) \ ExceptionalCondition(#condition, __FILE__, __LINE__); \ } while (0)
but on the other hand we don't care that much about micro-optimization of assert-enabled builds, so maybe that's not worth the trouble. The real win would be if constructs like
if (trouble) ereport(ERROR, ...);
could be interpreted as
if (unlikely(trouble)) ereport(ERROR, ...);
But I surely don't want to make thousands of such changes manually. And it's possible that smart compilers already realize this, using a heuristic that any path that ends in pg_unreachable() must be unlikely. Is there a way to encourage compilers to believe that?
