Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAtaR-0007cI-3g for pgsql-performance@arkaria.postgresql.org; Thu, 19 Sep 2019 10:22:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iAtaP-0003Ox-W3 for pgsql-performance@arkaria.postgresql.org; Thu, 19 Sep 2019 10:22:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iAtaP-0003Od-Ep for pgsql-performance@lists.postgresql.org; Thu, 19 Sep 2019 10:22:53 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iAtaI-0004Rj-Jc for pgsql-performance@lists.postgresql.org; Thu, 19 Sep 2019 10:22:52 +0000 Received: by mail-wm1-x333.google.com with SMTP id m18so860652wmc.1 for ; Thu, 19 Sep 2019 03:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=Zh+kQ0PrlSP7YlsA/ojfThDaJu85kzMWQJfkARnM5SE=; b=tU6tqtX3KyoobjvChKGDwToMHpWqy9RCxHtXUMS2H3/NohtSRCbSkBi9MPAlJNHC37 wAnDnOstNntfmPZZbj3U3LGFEC7/ZWUFL/u0lgP/WWjJ+33fmm34iyW9MdO4/fJgJKRq 3uXMG+N10mtzc+03KpIhpbLXPrcxR0HPdGtU+vcfuraEhT9NfPZR66oDf2cExPjAHX+I dIK9KuI3jJWvNusb0NvzPfIfbGOxoYukBcA/vEcV/bNeEtGBkb8BPrz5XEG63OreeGct op6BL0nSb3zI7nWHrnnWeRWZGOvqrmWrEhyEGkBgvNUkG0mXoTCgLlpz7QuoqxiFaSiz tkJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Zh+kQ0PrlSP7YlsA/ojfThDaJu85kzMWQJfkARnM5SE=; b=S25pE727J3v0EOvZF102oLTRRrVIM01HfIfWT81HOTkjQZdslZr/k9cV71xyruUTSP Ce9B4CHNKCUEQvECkIpLz6Z61OXmieMMsQI+fK1yy5BQ94S3tFKCyZL2SepfqtbhiAya 74i/7xUS5d/LXFggMaxOm81H5fo079d7gcoJrpBZOawpHIrgVeCPblr9itN7UMslyplT 4XnfG7ZIMJaaMvlhoeHakHyWP4nZb2yISDoH3vJDBoL+1R3WezceQPSMXYkbdwiW3dYu MaGzwsv2EMyujZ9WntlU15B5oESkEC5vUj4/842hgzJXF2xvU6be0i+NYxriIGCZnP0S BMiw== X-Gm-Message-State: APjAAAXoZKyksg6nsRCWKSV+nFXjqrDvsmCNJzZR3nuZ3F9AXfg2T9MN 2pr7KYTIngi7ZimVnRN4J9xO8Q== X-Google-Smtp-Source: APXvYqxWZq5Um4YM2gA2e89NXsujWPHIjGl35HIag1IuEeu382+qr8wXB/yqE+mv19HVV7I8EPNKPg== X-Received: by 2002:a05:600c:20e:: with SMTP id 14mr1367165wmi.73.1568888563772; Thu, 19 Sep 2019 03:22:43 -0700 (PDT) Received: from localhost.localdomain ([212.186.219.234]) by smtp.gmail.com with ESMTPSA id f197sm5728801wme.22.2019.09.19.03.22.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Sep 2019 03:22:43 -0700 (PDT) Message-ID: Subject: Re: Surprising benchmark count(1) vs. count(*) From: Laurenz Albe To: Thomas Kellerer , pgsql-performance@lists.postgresql.org Date: Thu, 19 Sep 2019 12:22:42 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, 2019-09-19 at 12:09 +0200, Thomas Kellerer wrote: > https://blog.jooq.org/2019/09/19/whats-faster-count-or-count1/ > > Is there a reason why count(*) seems to be faster? "count(*)" is just the SQL standard's way of saying what you'd normally call "count()", that is, an aggregate without arguments. "count(1)" has to check if 1 IS NULL for each row, because NULL values are not counted. "count(*)" doesn't have to do that. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com