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 1i5n7g-0002cW-Nu for pgsql-admin@arkaria.postgresql.org; Thu, 05 Sep 2019 08:28:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5n7f-000628-Jn for pgsql-admin@arkaria.postgresql.org; Thu, 05 Sep 2019 08:28:07 +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 1i5n7f-000602-5d for pgsql-admin@lists.postgresql.org; Thu, 05 Sep 2019 08:28:07 +0000 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5n7c-0006NC-IY for pgsql-admin@postgresql.org; Thu, 05 Sep 2019 08:28:06 +0000 Received: by mail-wr1-x431.google.com with SMTP id s18so1657328wrn.1 for ; Thu, 05 Sep 2019 01:28:03 -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=+rrd2gmIgkm0u/DXVi/r6CtZrXP9WoYTTJlIDvR5L18=; b=ropzS/xNknLjdyqp6Tr3ZkWeAN+mPFRJ2j51UANfS4nSA2LPbggx/wdCD18n6ah3wK rn1PIeA43JCv4SrrpD88QSv4D5GklSt9JPAjbGnmZL+vOSydDV8m74oHi25e2bzaPhv1 ZjEN6miUqwK130WM5W/n5noltwhBZL/sVgculw0OWxqV22+m0+EjLJxc3+/g+KT+F0mM W5k98kFfmLZ1d7r/03qBrNEl36/QMGNfBEcpP1Bc6wJin3nnfGEOQSljsmtyiXuOi3Jc 1eet6cgNiIVwWcvzs/p9CfSdUlJGhunoZBa8YTWZccn9cMm0HUw2px44/PJx1PnYAeI6 t9JQ== 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=+rrd2gmIgkm0u/DXVi/r6CtZrXP9WoYTTJlIDvR5L18=; b=dBvJvvJlwtiTyv6iI9XA0BpLOC15qgPm36yuTn8hwj8cAKEUPzrbcKrY+7aD2Urw7e eQDQztlBPizlhzy4nIpDEHxPlYYYVR1ahUeDyEoxlSBOod3OPbRgb80n9avZ4QlffyrP xe/aCaTetiSm8vXqlHUwxa2S6A7pIM7hCzb4I/DFQ5nmhD+v+kGGyYfJj+7XJs3s4KM2 Vdeo6277XydqGoQ5dftDz5/OmjiPNBVnKTHl6T5RtwLCohiha7P3SQNkRPpP6I3uB/lM QjOHK9Ceek7POf19blCA+PhLX6fQS34U5tu4136damGJDa60u1k7/LKJsujQHcLDqFWb NUtA== X-Gm-Message-State: APjAAAV+6OijdcWy5+SKHLkp9f61A/M9VgD+sJ8CMrTdQxaf81uLLTev 5DarFFQYS5BsqS1pLseNtdqtUC13K68= X-Google-Smtp-Source: APXvYqxpeU0GNMkvsfu7sN8h1rMn7kt32nI/l8W0kjKzDR8oLydJEVrglZerpqw/gdT6L1Y9echQ9Q== X-Received: by 2002:adf:f801:: with SMTP id s1mr1544833wrp.320.1567671708111; Thu, 05 Sep 2019 01:21:48 -0700 (PDT) Received: from localhost.localdomain ([212.186.219.234]) by smtp.gmail.com with ESMTPSA id w8sm7010416wmc.1.2019.09.05.01.21.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2019 01:21:47 -0700 (PDT) Message-ID: <2d38afc0f0f193b4a8b3762378dfd0bebd5ea5dd.camel@cybertec.at> Subject: Re: Version 11 partitioning: Constraint exclusion vs Partition Pruning From: Laurenz Albe To: Mark Steben , pgsql-admin Date: Thu, 05 Sep 2019 10:21:46 +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 Mark Steben wrote: > I am contemplating implementing partitioning in Postgres v 11. I am > reading the documentation and came across this statement in the > Constraint Exclusion section: > Constraint exclusion only works when the query's WHERE clause > contains constants (or externally supplied parameters). > Is this true also in Partition pruning? I don't see a similar > statement in that section. In v11, partition pruning will also work at query execution time, that is, you don't have to use a constant. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com