Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzX7u-0004WL-GQ for pgsql-performance@arkaria.postgresql.org; Tue, 21 Dec 2021 04:51:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mzX7s-0000WR-CX for pgsql-performance@arkaria.postgresql.org; Tue, 21 Dec 2021 04:51:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzX7r-0000WI-WD for pgsql-performance@lists.postgresql.org; Tue, 21 Dec 2021 04:51:48 +0000 Received: from mail-il1-x130.google.com ([2607:f8b0:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mzX7l-0002fR-9z for pgsql-performance@lists.postgresql.org; Tue, 21 Dec 2021 04:51:47 +0000 Received: by mail-il1-x130.google.com with SMTP id g5so778424ilj.12 for ; Mon, 20 Dec 2021 20:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sztlHjWaKuU16DY6l78yejGGPWQWbtUeuIjBJM9Lygw=; b=sWCffR+uOfOVl8Q7YV8G7dvZP6erpETd2f9tr2wPxf70s4BZlDg/VifIM76jLDSlpl /b4HC+EXdcErUrbn/CIC/GbZTmj8swptPhcd3ORhhiyfmvCpalzM1hohHg3iH3kkMB7X twJIKDfkhpmhmYbSkE46tfIeNQzicQWkka/2Kf9mk8CxInLzOWMKNuuNBbDAkiebouLb f8nUoxSSDzp7fv1PP2c3oOihdoW4HmlgvhosbDBEULrJamsGc12BAxJDdZu0tHGa4RP7 fKZbi+CT8psBz5s9XDVBikl/XKfy1JTLa9QQy8l+eobyfNFTviBt3WiRAuTgFwBIj/Qp NU9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sztlHjWaKuU16DY6l78yejGGPWQWbtUeuIjBJM9Lygw=; b=QqaLej0+121Kr894fYKCtvJHEXYIkP83jd6X1OJB4lliTSZvOgU2Q7UQYepk7eJm0y MIPc+7hUB8OmddzmupEKo/4dp+7UHzAaHjaKfTVElzKyCeRiY6axvjK1pR5EDDrEU8jq dii3jso8jPQmXmt50kEPtOSgW64xgxiUcHAA98Pg8IWE8ArcD4H2rUVwJajiSSMfISxq hp9v/MyTqxWgi+nT8lzFx3Lku2QYB63ZIdCLtylw6rA+tjTlXhpFAUtdpw2CSFSwbEcF sP8lh5iis9Cb/Gr9Fo+Gs3s5P+PFEJ5YNigB8+3VBrIzPGCni5bbTeFLajsN5SIragH3 iKjQ== X-Gm-Message-State: AOAM5320qF1JPBA+mN+vMPc39oc8htXNbyspwhBjIt1r0kAMnVsShpzk ONKyn0AG1fcSMRhQwSJTgvz51Q== X-Google-Smtp-Source: ABdhPJyeqTfpUJEHkMMjuMaQ11fHCFoBlMu7JL+664GyTE218HO0pKMXyUKOJtveBO4HkI4o/gAJvQ== X-Received: by 2002:a05:6e02:1b88:: with SMTP id h8mr614582ili.263.1640062299563; Mon, 20 Dec 2021 20:51:39 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id ay13sm12455401iob.37.2021.12.20.20.51.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Dec 2021 20:51:39 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 4CA4A8007F2; Mon, 20 Dec 2021 22:51:38 -0600 (CST) Date: Mon, 20 Dec 2021 22:51:38 -0600 From: Justin Pryzby To: Lars Bergeson Cc: Tom Lane , pgsql-performance@lists.postgresql.org Subject: Re: Query is slower with a large proportion of NULLs in several columns Message-ID: <20211221045138.GZ17618@telsasoft.com> References: <2688019.1640051519@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Dec 20, 2021 at 08:11:42PM -0800, Lars Bergeson wrote: > ok, here are results after I did: > set max_parallel_workers_per_gather = 0; > > HashAggregate (cost=1676432.13..1676432.16 rows=3 width=15) (actual time=19908.343..19908.345 rows=5 loops=1) > I/O Timings: read=532369.898 > Execution Time: 19908.383 ms > HashAggregate (cost=1390580.70..1390580.72 rows=2 width=15) (actual time=30369.758..30369.761 rows=5 loops=1) > I/O Timings: read=6440851.540 > Execution Time: 30369.796 ms > Still taking 10X more I/O to read the smaller table. Very odd. If I'm not wrong, it's even worse than that ? It takes 20 or 30sec to run the query - but it says the associated I/O times are ~500sec or ~6000sec ? What architecture and OS/version are you running ? How did you install postgres? From a package or compiled from source ? It might be interesting to know the output from something like this command, depending on whether and where the headers like pg_config_x86_64.h are installed. grep -r HAVE_CLOCK_GETTIME /usr/pgsql-13/include -- Justin