Re: Idea for cleaner representation of snapshots
От | Gregory Stark |
---|---|
Тема | Re: Idea for cleaner representation of snapshots |
Дата | |
Msg-id | 87k5x52lgq.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Idea for cleaner representation of snapshots (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Idea for cleaner representation of snapshots
|
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> It sounds like a fine idea from the point of view of flexibility. But as far >> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is >> used in contexts where the compiler is able to optimize away the conditionals >> or the cpu is able to predict them accurately. > > The compiler can't optimize away those conditionals, and even if the > hardware can predict them accurately, one predicted jump has to be > faster than five successive ones. The branch-prediction hardware works > for function pointer calls too (else C++ would be seriously slow). That's not really the point. The problem is that the compiler usually can't deduce which function you're calling or even which set of functions you might be calling. So, for example, the compiler will have trouble determining which variables may be untouched over the function call and thus not have to be reloaded into registers. Again though, I really don't think it matters. It might be 1% faster or 1% slower but HeapSatisfiesVisibility is itself only going to be a small fraction of the total time and so even on a heavily cpu-bound test we're talking about fractions of a percent either way. If it lets us do one algorithmic improvement we couldn't otherwise do the gain from that flexibility down the line will be many orders of magnitude larger and more important than a small microptimization. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: