Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHxvs-0000wl-2c for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Oct 2018 21:21:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHxvq-00057S-9S for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Oct 2018 21:21:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHxvp-00057K-V1 for pgsql-hackers@lists.postgresql.org; Wed, 31 Oct 2018 21:21:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHxvm-0001Wi-Ok; Wed, 31 Oct 2018 21:21:40 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w9VLLT0g015919; Wed, 31 Oct 2018 17:21:30 -0400 From: Tom Lane To: Amit Langote cc: Amit Langote , Alvaro Herrera , akorotkov@postgresql.org, bruno@wolff.to, PostgreSQL Hackers Subject: Re: Should pg 11 use a lot more memory building an spgist index? In-reply-to: References: <20181026140927.oh4gd367st47li6h@alvherre.pgsql> <26004.1540563602@sss.pgh.pa.us> <20752.1540842517@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Wed, 31 Oct 2018 10:50:19 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15916.1541020889.1@sss.pgh.pa.us> Date: Wed, 31 Oct 2018 17:21:29 -0400 Message-ID: <15917.1541020889@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > Maybe, we don't need to spoil the interface of index_beginscan with the > new memory context argument like my patch does if the simple following of > its contract by amendscan would suffice. Yeah, I'm not enamored of changing the API of index_beginscan for this; the existing convention that it should allocate in CurrentMemoryContext seems perfectly suitable. And changing it would create a lot of code churn, not only for us but for externally-maintained AMs. What is at stake is changing the API of amendscan, to specify that it need not release memory because the current context is expected to be destroyed or reset shortly after ending the scan. Then, for the small number of call sites where that wouldn't be true, it's on those callers to set up a suitable context and switch into it. Note this is actually forwards compatible, in that an AM that's still following the convention of releasing stuff manually would not be broken. regards, tom lane