Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eePmy-0002FK-Dq for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jan 2018 18:28:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eePmx-0008Ar-RW for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jan 2018 18:28:47 +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 1eePmx-0008Aa-HY for pgsql-hackers@lists.postgresql.org; Wed, 24 Jan 2018 18:28:47 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eePmu-000227-5i for pgsql-hackers@postgresql.org; Wed, 24 Jan 2018 18:28:46 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B4DD722450; Wed, 24 Jan 2018 13:28:42 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 24 Jan 2018 13:28:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mz8LUMR4km3DDuohvbTpg+CMb2JbH 05oM71iIfpQivo=; b=JpdTtizVP39sV51apxcv92jwrJiaNdkaYBDaO0Ka2H7fT yMrm8aQtxbHepAT8uBGcyRrq2lnNDElKc4U/lXNbvhnu+sqMsAljmBE+lMiSuP17 AVnGDNX6maW8ohpqpmyC8FTFWf3hquENa2lGMOCOBCzNj+m7yZZJ0lngiTV8b4eN MkY7mTEV6bMYQ7Ghmb4IWbPa39scJV46ig/El4zTxoZcEHOFHP8DZbErBvXoMPEh m6xY7ZkMfVb2cG49pRhnypFNzN3iyHEsXGFHVe5ftOJVaQdWUud5v5o3yPf8O5/m qRsi/cirskS1e8/8flhgiU14u1dqwwQzqUPR0yY8w== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C31C240F8; Wed, 24 Jan 2018 13:28:42 -0500 (EST) Date: Wed, 24 Jan 2018 10:28:41 -0800 From: Andres Freund To: Robert Haas Cc: Tom Lane , Thomas Munro , "pgsql-hackers@postgresql.org" Subject: Re: pgsql: Add parallel-aware hash joins. Message-ID: <20180124182841.ep7yr6tgqazsoilu@alap3.anarazel.de> References: <30219.1514428346@sss.pgh.pa.us> <4503.1514435195@sss.pgh.pa.us> <21339.1516633310@sss.pgh.pa.us> <24384.1516665190@sss.pgh.pa.us> <12736.1516749056@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2018-01-24 13:11:22 -0500, Robert Haas wrote: > So for me, the additional hash index tests don't cost anything > measurable and the additional hash join tests cost about a second. I > think this probably accounts for why committers other than you keep > "adding so much time to the regression tests". On modern hardware, > the costs just don't matter. I very much agree with the general sentiment, but a second of a 25s test certainly isn't nothing. As I've just written a few messages upthread, I think we can hide the overall timing costs to a much larger degree than we're doing, but I don't think we need not pay attention at all. > Now, how much should we care about the performance of software with a > planned release date of 2018 on hardware discontinued in 2001, > hardware that is apparently about 20 times slower than a modern > laptop? Some, perhaps, but maybe not a whole lot. Removing tests > that have found actual bugs because they cost runtime on ancient > systems that nobody uses for serious work doesn't make sense to me. I again agree with the sentiment. One caveat is that old machines also somewhat approximate testing with more instrumentation / debugging enabled (say valgrind, CLOBBER_CACHE_ALWAYS, etc). So removing excessive test overhead has still quite some benefits. But I definitely do not want to lower coverage to achieve it. Greetings, Andres Freund