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 1j5oFJ-0000cc-Nz for pgsql-performance@arkaria.postgresql.org; Sun, 23 Feb 2020 10:12:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j5oFG-0005VB-RD for pgsql-performance@arkaria.postgresql.org; Sun, 23 Feb 2020 10:12:18 +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 1j5oFG-0005Sv-87 for pgsql-performance@lists.postgresql.org; Sun, 23 Feb 2020 10:12:18 +0000 Received: from mail-yb1-xb44.google.com ([2607:f8b0:4864:20::b44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j5oFA-00048j-SL for pgsql-performance@lists.postgresql.org; Sun, 23 Feb 2020 10:12:16 +0000 Received: by mail-yb1-xb44.google.com with SMTP id b196so2772768yba.4 for ; Sun, 23 Feb 2020 02:12:12 -0800 (PST) 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=kGJVC/1cE0nHHU15Hgvuob2cYy+umsEdY6I1q+Ldwe8=; b=o1v8RAw3vhV241BQNKZONJdSJ2ZLK9UYx77o8Tlv7YMc2146pcuqKG314IsRcRsM7q vg2cPkhuqnJ1L1OuXdbosljAY5cvixIeMkR7MFm1Toa82t/TPgcKcFkWQKFhMSWv47wC W8XM9+EzwHDQrVy+e6pd7xP8Qsn0nbURBWnbiTkl6gBhOtjAM3mTrtP10GH7xoq5vYwl CPr0euxImPnJp10fYI5mX0JXcqSfATAlawpMPlD2Ko6ReDzi2TG2aCuctLRUcWG9nO87 8Eho045QrNMKY7I/Af1J1DtO5VvQvnuc9rSi5+tsqKiZumkzIJFHYkaF6+J5GAnTCaSf 21JA== 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=kGJVC/1cE0nHHU15Hgvuob2cYy+umsEdY6I1q+Ldwe8=; b=VcjdVpssoEW3dqIqXY5DgfjKWOqnPVUSrL+HeeqbxY2tANM7bPqcGY0d3MAPlgYZfP TuDmiuRmeKuTnoGpyucWAICU0cF/GHH5YSUWEBSRLHygTkKku5dWojckPsO5Nc2TaYAM mYKeqM0XQ4F99eUXgvF9wbcmC5LD8ipNEvGWgsYCvi3f2S3ga/daHnID/euQ23lPl6ZH x8ESSuOEegIsvGfa8JV9z5Xwrt3aVtbkHd3QzTYg6cQZtTMfQUca300SkMmATFBOQVCZ +xRo/3v1AuAQ1AB7LqMh008ERVJfE0KmAjx8b9UTnnOgaI+8kjsDfUbyBeI42e0vrcY6 UDgQ== X-Gm-Message-State: APjAAAVL7sXPqHGhWF93zn43yEtKZYKbdhVBxwV3t3G/e/8TjJmBDCvq jgi64ew8GsHRWtzf+FQ1+bs+2Yv/J5k= X-Google-Smtp-Source: APXvYqxqyjQgnEZ3jCMawOKTF6daJn6gKRh+DSr/hQIIANMQL26ctjCG0TUl4/c0YauZV9sOK1mMRg== X-Received: by 2002:a25:8045:: with SMTP id a5mr25874099ybn.118.1582452731274; Sun, 23 Feb 2020 02:12:11 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i72sm3758839ywg.49.2020.02.23.02.12.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2020 02:12:10 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 41456800828; Sun, 23 Feb 2020 04:12:09 -0600 (CST) Date: Sun, 23 Feb 2020 04:12:09 -0600 From: Justin Pryzby To: Ravi Garg Cc: pgsql-performance@lists.postgresql.org Subject: Re: PostgreSQL 11 higher Planning time on Partitioned table Message-ID: <20200223101209.GU31889@telsasoft.com> References: <1789489940.5008704.1582451790367.ref@mail.yahoo.com> <1789489940.5008704.1582451790367@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1789489940.5008704.1582451790367@mail.yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Feb 23, 2020 at 09:56:30AM +0000, Ravi Garg wrote: > Hi, > I am looking to Range Partition one of my table (i.e. TransactionLog) in PostgreSQL 11.While evaluating query performance difference between the un-partitioned and partitioned table I am getting huge difference in planning time. Planning time is very high on partitioned table.Similarly when I query by specifying partition name directly in query the planning time is much less **0.081 ms** as compared to when I query based on partition table (parent table) name in query, where planning time **6.231 ms** (Samples below).
That's probably to be expected under pg11: https://www.postgresql.org/docs/11/ddl-partitioning.html |Too many partitions can mean longer query planning times... |It is also important to consider the overhead of partitioning during query planning and execution. The query planner is generally able to handle partition hierarchies with up to a few hundred partitions fairly well, provided that typical queries allow the query planner to prune all but a small number of partitions. Planning times become longer and memory consumption becomes higher as more partitions are added > There are around ~200 child partitions. Partition pruning enabled.PostgreSQL Version: PostgreSQL 11.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit How large are the partitions and how many indexes each, and how large are they? Each partition will be stat()ed and each index will be open()ed and read() for every query. This was resolved in pg12: https://commitfest.postgresql.org/21/1778/ -- Justin