| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP: Faster Expression Processing v4 |
| Date: | 2017-03-27 16:18:59 |
| Message-ID: | 20170327161859.zzdsmbpnnayqh77y@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-03-27 11:52:05 -0400, Tom Lane wrote:
> 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.
Gah :(. I have gcc 5,6,7 here, but nothing earlier. I'm now inclined
to go the version check routine, for the individual versions we can (and
want) confirm this on... I'm not too concerned about not doing so on
gcc 4.4 or older...
> 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.
Indeed.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-27 16:19:05 | Re: [COMMITTERS] pgsql: Improve performance of find_all_inheritors() |
| Previous Message | Tom Lane | 2017-03-27 16:18:37 | Re: WIP: Faster Expression Processing v4 |