Re: hyrax vs. RelationBuildPartitionDesc - Mailing list pgsql-hackers

From Robert Haas
Subject Re: hyrax vs. RelationBuildPartitionDesc
Date
Msg-id CA+Tgmoaci6KaV3dyQADosfHyCVHB-8XeYkXY7GFebH1a_7Zr5A@mail.gmail.com
Whole thread Raw
In response to Re: hyrax vs. RelationBuildPartitionDesc  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 13, 2019 at 1:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm a bit confused as to why there's an issue here at all.  The usual
> plan for computed-on-demand relcache sub-structures is that we compute
> a working copy that we're going to return to the caller using the
> caller's context (which is presumably statement-duration at most)
> and then do the equivalent of copyObject to stash a long-lived copy
> into the relcache context.  Is this case being done differently, and if
> so why?  If it's being done the same, where are we leaking?

It's being done in just that way.  The caller's context is
MessageContext, which is indeed statement duration.  But if you plunk
10k into MessageContext a few thousand times per statement, then you
chew through a couple hundred meg of memory, and apparently hyrax
can't tolerate that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL
Next
From: Tom Lane
Date:
Subject: Re: hyrax vs. RelationBuildPartitionDesc