Re: Re[2]: [PATCH] Change simple_heap_insert() to a macro

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrey Klychkov <aaklychkov(at)mail(dot)ru>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re[2]: [PATCH] Change simple_heap_insert() to a macro
Date: 2018-10-15 17:00:38
Message-ID: 2447.1539622838@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?B?QW5kcmV5IEtseWNoa292?= <aaklychkov(at)mail(dot)ru> writes:
>>  simple_heap_insert() is used in catalog updates and such. Does that have
>>  any measurable performance impact?

> I guess this change doesn't give us an incredible performance increase except there will no redundant function call.
> I don't see any reasons against to use the proposed macro instead of this function.

Well, by the same token, there's no reason in favor either.

In this particular case I'd vote against because the macro requires
more side-knowledge than the function call, ie GetCurrentCommandId
has to be in-scope for every caller. It's not hard to imagine
future changes that would make that problem worse.

In general, without a clearly measurable performance benefit,
changing functions into macros or inlines isn't a good idea.
The code churn poses hazards for back-patching, and there's
usually some physical code bloat due to more instructions being
needed at each call site.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2018-10-15 17:21:04 Error handling expectations
Previous Message Tom Lane 2018-10-15 16:32:21 Re: constraints names on partitions