Re: WIP: Faster Expression Processing v4 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Faster Expression Processing v4
Date
Msg-id 31039.1490629925@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP: Faster Expression Processing v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
As to the point of whether it actually helps or not ...

on gcc 6.3.1 (Fedora 25), yes it does.  Seems to be one "jmp *something"
per EEO_NEXT or EEO_JUMP.

on gcc 4.4.7 (RHEL 6), it makes things *WORSE*.  We go from about half of
the dispatches getting routed through a common location, to *all* of them
(except one; for some odd reason the first EEO_NEXT in EEOP_NULLIF
survives as a separate jump).  This seems like a bug, but there it is.

So this means we'd need some serious research to decide whether to apply
it.  And I'm suspecting we'd end up with a compiler version test.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: crashes due to setting max_parallel_workers=0
Next
From: Jeff Janes
Date:
Subject: Re: segfault in hot standby for hash indexes