Horton
Menu

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Bruno Wolff III <bruno@wolff.to>, pgsql-general@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Date: 2018-10-26T14:09:27Z
Lists: pgsql-hackers 
On 2018-Oct-26, Tom Lane wrote:

> After a quick look around, I think that making systable_begin/endscan
> do this is a nonstarter; there are just too many call sites that would
> be affected.  Now, you could imagine specifying that indexes on system
> catalogs (in practice, only btree) have to clean up at endscan time
> but other index types don't, so that only operations that might be
> scanning user indexes need to have suitable wrapping contexts.  Not sure
> there's a lot of benefit to that, though.

How about modifying SysScanDescData to have a memory context member,
which is created by systable_beginscan and destroyed by endscan?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix memory leak in repeated SPGIST index scans.

  2. Add support for nearest-neighbor (KNN) searches to SP-GiST