On Tue, Nov 01, 2011 at 10:55:02AM -0400, Robert Haas wrote:
> Well, the obvious problem is that we might end up spending a lot of
> work on something that doesn't actually improve performance, or even
> makes it worse, if our guesses about what's likely and unlikely turn
> out to be wrong. If we can show cases where it reliably produces a
> significant speedup, then I would think it would be worthwhile, but I
> think we should probably start by looking at what's slow and see how
> it can best be made faster rather than by looking specifically for
> places to use likely() and unlikely().
The biggest problem here is that (usually) the time is going in
branches other than the ones you're thinking of.
Something that might be interesting to try profile branch feedback in
GCC. If you let the profiler see how often each branch was taken and
then feed this back into the compiler you get in principle the best
case result. This would represent the possible best case scenario. If
you can prove a measurable difference then you know it's worth
pursuing. If there's no result, then you know that too...
Mind you, getting profile data with postgresql's multiprocess
architechture can be challenge.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts. -- Arthur Schopenhauer
