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 1h46xl-0008Ez-IF for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 16:42:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h46xk-0005nm-3y for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Mar 2019 16:42:40 +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 1h46xj-0005mt-Ln for pgsql-hackers@lists.postgresql.org; Wed, 13 Mar 2019 16:42:39 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h46xg-0005MH-CD for pgsql-hackers@lists.postgresql.org; Wed, 13 Mar 2019 16:42:38 +0000 Received: by mail-qt1-x841.google.com with SMTP id v20so2638613qtv.12 for ; Wed, 13 Mar 2019 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LEuvIlh3DCsJ9JttxPEXGS2D/+3AdFPMca3dCr/FuR4=; b=L4rPl+iGs532Y5hHQFjx1xRElDi+DtpkD1hfpz/yUIQr2zRSGEBqCTA00UBn92BrQa 7LrTJOTpup4x3FBV5K0uw6tjpleZHWJdkG4zT4aVcPXHTAkU8n5jwRAMtS3vj8GMfkvV OsAuW/NBxjS4w/ngBSxqu5QkQT+jok91m0YGm/h82qtXQXo6OUFTZopKVP71dObLtMN0 WQpbMzVaH3dHv6EtZf5KOKdFf5soyc6G2wPuhMeZ3BzCpmQpdAE0NJGXzgEOT28GrP+z xIWgT/FRqA9R/199+ISM6zNMDEyZKI+RYH90RndL7AXkqrnmRdtK7kf5KMlOKbziPdpj kuJA== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=LEuvIlh3DCsJ9JttxPEXGS2D/+3AdFPMca3dCr/FuR4=; b=L50GNZx5MrIjuQMPFPCg2FlMwGDVxOZnRBn6vhgpyw9TjXsW4akjAmmknhcKwv+UvR mE8AVxw9gNaRWkBVZx8Dx/MzM/A6CxG99YqbWmW++A4rKXRvkpUUGtau4p4sYazajT7M ebVAnO//9nuGi4iQS0tiqSY6ufDoiUwmQ0wdz+7F7nCifjhelDyzf25ah9OsbMuljacD Cuy5K1biqB6e2Lno+IcejiCN9Kc8QH6VazB5yTiPWH/Hu92EzdIZALL33EYM+iJCvVLM C5Bllwf4AeH/fnEY80sp1fcXnEGjKNEuI5MaDoRuTkJv0XiqBCOyDhaDkgRHVDPY8gw3 ht4Q== X-Gm-Message-State: APjAAAVnXjaIgEI8He8v1EhVmckkG82/+dYJI3WBsSWxZK3nS9YR2S++ YrzJ6VhS0sOJoSe9FI2BMcS3oQ== X-Google-Smtp-Source: APXvYqyp4zCarhyj6Myq4WXIUfbT4eL1izTJE9wkXPL3XorwiBK5Oiuy9VCkokcoarRzMSSyOEXJhg== X-Received: by 2002:a0c:804b:: with SMTP id 69mr35518884qva.133.1552495355083; Wed, 13 Mar 2019 09:42:35 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id i6sm6429190qkk.54.2019.03.13.09.42.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Mar 2019 09:42:34 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id A66D7121CAE; Wed, 13 Mar 2019 13:42:32 -0300 (-03) Date: Wed, 13 Mar 2019 13:42:32 -0300 From: Alvaro Herrera To: Robert Haas Cc: PostgreSQL Hackers Subject: Re: hyrax vs. RelationBuildPartitionDesc Message-ID: <20190313164232.GA5270@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Mar-13, Robert Haas wrote: > RelationBuildPartitionDesc() creates basically all of the data > structures it needs and then copies them into rel->rd_pdcxt, which has > always seemed a bit inefficient to me. Another way to redesign this > would be to have the function create a temporary context, do all of > its work there, and then reparent the context under CacheMemoryContext > at the end. That means any leaks would go into a relatively > long-lifespan context, but on the other hand you wouldn't leak into > the same context a zillion times over, and you'd save the expense of > copying everything. I think that the biggest thing that is being > copied around here is the partition bounds, so maybe the leak wouldn't > amount to much, and we could also do things like list_free(inhoids) to > make it a little tighter. I remember going over this code's memory allocation strategy a bit to avoid the copy while not incurring potential leaks CacheMemoryContext; as I recall, my idea was to use two contexts, one of which is temporary and used for any potentially leaky callees, and destroyed at the end of the function, and the other contains the good stuff and is reparented to CacheMemoryContext at the end. So if you have any accidental leaks, they don't affect a long-lived context. You have to be mindful of not calling leaky code when you're using the permanent one. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services