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.92) (envelope-from ) id 1jBHGm-0004yc-T0 for pgsql-performance@arkaria.postgresql.org; Mon, 09 Mar 2020 12:12:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jBHGk-0007Ic-Q2 for pgsql-performance@arkaria.postgresql.org; Mon, 09 Mar 2020 12:12:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jBHGk-0007IU-Bv for pgsql-performance@lists.postgresql.org; Mon, 09 Mar 2020 12:12:26 +0000 Received: from mail-yw1-xc41.google.com ([2607:f8b0:4864:20::c41]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jBHGc-0002lG-IJ for pgsql-performance@lists.postgresql.org; Mon, 09 Mar 2020 12:12:25 +0000 Received: by mail-yw1-xc41.google.com with SMTP id o186so9906687ywc.1 for ; Mon, 09 Mar 2020 05:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7oYZ7TMnoHL5S9KsAC9VEiCD0CClRmLUPzPye8AhiiA=; b=1Y2b6i7vNg6r+9llW6Xs0Fu7gCZ+VfwQL1qgr4SNPPx+BU3ee4/rW8fSGtLIUoi0nf 6Z9NpYk4Tq/HGf2wlHJc3lSEvyFQK2+euA2XYxMSzlDdvK7G3JPchUwxFJ2R5gZdJXzR WJZjQ69Y2kyqlgND4kHrBH4rLrS9riZdTipmOgwlY/ULmQaJxkqq6wpkKAPZKk8bRvV0 6x8kpPCh/ounN9lHCOJbB4efG6xi7EH24a7meXr29g3eMts9o2S34X+J1/9dh7Xv8OWx Ui5IAdeMm/4Gf6ye978CdHl2XypVZ9Xs5dwDSrjonh2cR/B0OQ2F9Nj1yLE+aip2t2UE 1+mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=7oYZ7TMnoHL5S9KsAC9VEiCD0CClRmLUPzPye8AhiiA=; b=Pa5kWGE3ZrmUaHM2dquYdXujBCshwesb7iapfquQ1WyksxvWhMgY7kKHGq3R7My+WE NGNfWyBn35vSJFOnIpaMPQ7uWU+RAA0fyAbWTU+fYo1i7dw2lIt41e6JQXp27jc09P3m pPa1kKjFjic3k+uEWONRVBRvvTiXID46IZ5khBBE3d3gVI7Z0FegAu9+0La5DsutoIGl S2/BS8IYpKUVZabspl9bpZ0kTG/20ooilcoHEod0hNqKC3QJNJpinCgtaPlcD0vzUW8y YdGeRHbgoxEvD9M1r8itC1vDW3xW3yxIrphwRxNEIFLIv7TecSjwy5pyrh0Zx0U4EITS icyw== X-Gm-Message-State: ANhLgQ11mXdajEraxuD+SY4QbUJ3dmomGSVgyrSUTPEbL/UYbUgzVwFz ZncFBjUWKLrYZPLE+cHAFzm1Mw== X-Google-Smtp-Source: ADFU+vuBwXwWzLqFfA6liR049HenQnGiVLDXeT77e2KWnMkqGoCMPJ4XUAgEfj4l7o/4A2ZVodOyrg== X-Received: by 2002:a81:700f:: with SMTP id l15mr16111166ywc.227.1583755935415; Mon, 09 Mar 2020 05:12:15 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e63sm17185996ywd.64.2020.03.09.05.12.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 05:12:14 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 1ADC7800827; Mon, 9 Mar 2020 07:12:13 -0500 (CDT) Date: Mon, 9 Mar 2020 07:12:13 -0500 From: Justin Pryzby To: Mariel Cherkassky Cc: pgsql-performance@lists.postgresql.org Subject: Re: pg12 partitions show bad performance vs pg96 Message-ID: <20200309121212.GF1357@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Mar 09, 2020 at 12:31:15PM +0200, Mariel Cherkassky wrote: > > I tried to do even something simpler, run the query with only the > > partition column in the where clause and the results werent good for pg12 : > > PG12 : > postgres=# explain analyze select * from iot_data where device=51; > QUERY PLAN > --------------------------------------------------------------------------------------------------------------------------------------- > Gather (cost=1000.00..514086.40 rows=1027284 width=37) (actual time=6.777..61558.272 rows=1010315 loops=1) > Workers Planned: 2 > Workers Launched: 2 > -> Parallel Seq Scan on iot_data_0 (cost=0.00..410358.00 rows=428035 width=37) (actual time=1.152..61414.483 rows=336772 loops=3) For whatever reason, your storage/OS seem to be handling parallel reads poorly. I would SET max_parallel_workers_per_gather=0 and retest (but also look into improving the storage). Also, it's not required, but I think a typical partitioning schema would have an index on the column being partitioned. I see you have an index on iot_data(metadata,lower(data)), so I still wonder whether you'd have better results partitioned on metadata, or otherwise maybe adding an index on "device". But I don't know what your typical queries are. > PG9.6 > postgres=# explain analyze select * from iot_data where device=51; > QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------- > Seq Scan on iot_data (cost=0.00..2083334.60 rows=976667 width=37) (actual time=21.922..16753.492 rows=1010315 loops=1) -- Justin