Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csXNe-0000cZ-KC for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Mar 2017 16:20:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1csXNe-0002WX-6q for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Mar 2017 16:20:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1csXM7-0003Kj-2p for pgsql-hackers@postgresql.org; Mon, 27 Mar 2017 16:18:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1csXM4-0007sa-FL for pgsql-hackers@postgresql.org; Mon, 27 Mar 2017 16:18:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v2RGIbON032161; Mon, 27 Mar 2017 12:18:38 -0400 From: Tom Lane To: Andres Freund cc: Ants Aasma , Heikki Linnakangas , Tomas Vondra , PostgreSQL-development Subject: Re: WIP: Faster Expression Processing v4 In-reply-to: <31039.1490629925@sss.pgh.pa.us> References: <5768.1490458935@sss.pgh.pa.us> <20170325222202.uz6evsjqrtwjnql6@alap3.anarazel.de> <3CC5B4C5-3ADB-4296-A04B-64F594A4CE4F@anarazel.de> <23529.1490500305@sss.pgh.pa.us> <20170326035927.5mubkfdtaqlrgm2d@alap3.anarazel.de> <20170327054314.qo6xsnlk7jcb7u2c@alap3.anarazel.de> <15684.1490621623@sss.pgh.pa.us> <20170327151750.dnpxtkjjade7kiv6@alap3.anarazel.de> <19784.1490628160@sss.pgh.pa.us> <20170327152914.m3firc6rkx5tqtgo@alap3.anarazel.de> <31039.1490629925@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 27 Mar 2017 11:52:05 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32159.1490631517.1@sss.pgh.pa.us> Date: Mon, 27 Mar 2017 12:18:37 -0400 Message-ID: <32160.1490631517@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org I wrote: > As to the point of whether it actually helps or not ... > 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 after a bit of googling, this is a very longstanding complaint: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 (hm, think I know the second submitter) I'm not sure we should be relying on a gcc bug fix that's barely four months old. Even assuming it fixes the issue without new regressions, most people are not going to have it anytime soon. My feeling at this point is that we might be better off disabling the computed-goto case by default. At the very least, we're going to need a version check that restricts it to latest gcc. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers