| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Maksim Milyutin <milyutinma(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: Proposal: Local indexes for partitioned table |
| Date: | 2017-10-27 20:18:06 |
| Message-ID: | CA+TgmoZ6z8+PqygTR=yC=tFCMJ6uUYWTLFKTSKXaHu=jYCjLLg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 27, 2017 at 7:27 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> I noticed that RelationBuildPartitionKey is generating a partition key
> in a temp context, then creating a private context and copying the key
> into that. That seems leftover from some previous iteration of some
> other patch; I think it's pretty reasonable to create the new context
> right from the start and allocate the key there directly instead. Then
> there's no need for copy_partition_key at all.
We could do that, but the motivation for the current system was to
avoid leaking memory in a long-lived context. I think the same
technique is used elsewhere for similar reasons. I admit I haven't
checked whether there would actually be a leak here if we did it as
you propose, but I wouldn't find it at all surprising.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-10-27 20:32:12 | Re: Parallel safety for extern params |
| Previous Message | Tomas Vondra | 2017-10-27 20:09:16 | Re: WIP: BRIN bloom indexes |