| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 15:52:05 |
| Message-ID: | 31039.1490629925@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2017-03-27 15:56:55 | Re: segfault in hot standby for hash indexes |
| Previous Message | Robert Haas | 2017-03-27 15:51:05 | Re: crashes due to setting max_parallel_workers=0 |