| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: hyrax vs. RelationBuildPartitionDesc |
| Date: | 2019-03-13 17:27:08 |
| Message-ID: | CA+Tgmoaci6KaV3dyQADosfHyCVHB-8XeYkXY7GFebH1a_7Zr5A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 13, 2019 at 1:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-03-13 17:30:52 | Re: hyrax vs. RelationBuildPartitionDesc |
| Previous Message | Robert Haas | 2019-03-13 17:25:11 | Re: using index or check in ALTER TABLE SET NOT NULL |