Re: Extensible executor nodes for preparation of SQL/MED

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Extensible executor nodes for preparation of SQL/MED
Дата
Msg-id AANLkTin7kZ-VCzANv3Jc-6Vyw=44hVgNwniNZyT47-bS@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extensible executor nodes for preparation of SQL/MED  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Extensible executor nodes for preparation of SQL/MED  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> But it might be a good change anyway from a performance standpoint,
> in case a call through a function pointer is faster than a big switch.
> Have you tried benchmarking it on common platforms?

I've always wondered why we didn't use function pointers. It seems
like it would make the code a lot easier to maintain with fewer places
that need to be updated every time we add a node.

But I always assumed a big part of the reason was performance.
Generally compilers hate optimizing code using function pointers. They
pretty much kill any inter-procedural optimization since it's very
hard to figure out what set of functions you might have called and
make any deductions about what side effects those functions might or
might not have had. Even at the chip level function pointers tend to
be slow since they cause full pipeline stalls where the processor has
no idea where the next instruction is coming from until it's finished
loading the data from the previous instruction.

On the other hand of course it's not obvious what algorithm gcc should
use to implement largish switch statements like these. It might be
doing a fairly large number of operations doing a binary search or
hash lookup to determine which branch to take.


-- 
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: foreign keys for array/period contains relationships
Следующее
От: Robert Haas
Дата:
Сообщение: Re: security label error message