Re: Should pg 11 use a lot more memory building an spgist index?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, akorotkov(at)postgresql(dot)org, bruno(at)wolff(dot)to, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should pg 11 use a lot more memory building an spgist index?
Date: 2018-10-31 21:21:29
Message-ID: 15917.1541020889@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rich Shepard 2018-10-31 21:28:02 Re: Broken postgres links need to find callers
Previous Message Rich Shepard 2018-10-31 21:09:16 Re: Broken postgres links need to find callers

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-10-31 22:22:43 Re: PostgreSQL Limits and lack of documentation about them.
Previous Message Tom Lane 2018-10-31 21:11:16 Re: Parallel threads in query