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 1hQk9K-00059R-DN for pgsql-advocacy@arkaria.postgresql.org; Wed, 15 May 2019 03:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hQk9I-000313-IV for pgsql-advocacy@arkaria.postgresql.org; Wed, 15 May 2019 03:00:08 +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 1hQk9I-00030v-72 for pgsql-advocacy@lists.postgresql.org; Wed, 15 May 2019 03:00:08 +0000 Received: from mail-it1-x141.google.com ([2607:f8b0:4864:20::141]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQk9D-00074L-Ah for pgsql-advocacy@lists.postgresql.org; Wed, 15 May 2019 03:00:06 +0000 Received: by mail-it1-x141.google.com with SMTP id u186so2236557ith.0 for ; Tue, 14 May 2019 20:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/NJqYvoSI56gya6cAfeIR6puj4FhqLCcZI4xSi8fNcU=; b=C4DAE4fc6mcSlU4uy5iSsU3qo0VB8ZqoayxWqYnDEU0FKFBkp4xEGfGMUSA74cvUfk NaH9aS0AgcseeDCOoS4DDO9QC66ChnKGJRWwfAwHmWlm5V6jFKuHaI3hHC7CdUMoa/8/ 9dG7o8NphGj5eztc2OeF4p0iKl+wPK5NGp9L/AdJuH2IDMNQ8smXfPUGbJ4U6mRT1SRV cLrfBf5CCf0rZQVthscqWreIV/magQSVdPheY58UxNxBC+dGl3Z+Q7rbLjSqOUgvhKkk /GqqhZaRaMoyoQYAq64JSoQHHVB/ggcazyvKCSfdWrB/TNlJRdqBSDvSsMKHZA8M6BRQ 4GLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/NJqYvoSI56gya6cAfeIR6puj4FhqLCcZI4xSi8fNcU=; b=j/o5zSBDs1Fs89Qe9SwSmmMVM2JzRu8YnirbOOeT+Xw7Q60xaDlrrdk5iQtEoB6xhJ NMSYYaupzdPsRtYlG2HpfDnNq1K9Znfpqmzf3s6X+DXvTCvOvdcy/5BjzOpsCUCyJplh leLa8tx65ewjihER1Pp+/lyiYf8Zs6TQOX9BLNHP5whPVEbCxHnVlXvBvhzybKt2iCJo sL0YY9wsqEP0L24eL/Gm0eFiZdNniTLkr2pzYQzBnugLwgT8gh5PAEDwyzuuRvQ2+VdQ +jMRFpOr6ST5Svly3h0n4ZsVl2YU/4GeVxVk/theqqF9F6pAZgOgWAsOBsgfCfgVre1G Xptw== X-Gm-Message-State: APjAAAV2phIfy7Uaq/0E3SKrIqqMoKINiojE/Q2xDPN0KW07L8QzbeH8 irE6e3QAdgicFWaDNOX4nWLbTTHLOdolwlCgi7bw5w== X-Google-Smtp-Source: APXvYqyAkMxPIKpXrabSh4q7jaB/uof1pvLQKFqvd97z2Ju2jjMc3v8SRobbCfOnHH0v8AX5JPCqGMLyHtWf5gzPNgs= X-Received: by 2002:a24:58d:: with SMTP id 135mr6030615itl.3.1557889202461; Tue, 14 May 2019 20:00:02 -0700 (PDT) MIME-Version: 1.0 References: <830415f7-78ec-ef7b-0f73-0e810ef87f91@postgresql.org> In-Reply-To: From: David Rowley Date: Wed, 15 May 2019 14:59:48 +1200 Message-ID: Subject: Re: PostgreSQL 12: Feature Highlights To: Amit Langote Cc: "Jonathan S. Katz" , pgsql-advocacy@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, 15 May 2019 at 14:31, Amit Langote wrote: > > On 2019/05/15 11:03, Jonathan S. Katz wrote: > > 2. Partitioning Improvements > > > > - Improved partition pruning, which improves performance on queries over > > tables with thousands of partitions that only need to use a few partitions > > - Improvements to COPY performance and ATTACH PARTITION > > - Allow foreign keys to reference partitioned tables > > About the 1st item in "Partitioning Improvements", it's not just partition > pruning that's gotten better. How about writing as: > > - Improved performance of processing tables with thousands of partitions > for operations that only need to touch a small number of partitions > > Per discussion upthread, that covers improvements to both partition > pruning and tuple routing. +1. Amit's words look fine to me. I think if we're including this as a headline feature then it should be to inform people that partitioning is generally more useable with larger numbers of partitions, not just that SELECT/UPDATE/DELETE now perform better when pruning many partitions. The work done there and what's done to speed up tuple routing in INSERT/COPY both complement each other, so they're likely good to keep as one in the headline features list. Mentioning one without the other might leave some people guessing about if we've addressed the other deficiencies with partitioning performance. Sadly, they can't refer to the release notes for more information since they don't detail what's changed in this area :( -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services