| 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 20:50:53 |
| Message-ID: | CA+TgmoZVzrnX+tCQX9O-rPhddivvJUsAJ0P2H7GuPzc3DEbBwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 13, 2019 at 4:38 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Off topic for the moment, since this clearly wouldn't be back-patch
> > material, but I'm starting to wonder if we should just have a context
> > for each relcache entry and get rid of most or all of the retail
> > cleanup logic in RelationDestroyRelation ...
>
> I think that idea might have a lot of merit, but I haven't studied it closely.
It just occurred to me that one advantage of this would be that you
could see how much memory was being used by each relcache entry using
MemoryContextStats(), which seems super-appealing. In fact, what
about getting rid of all allocations in CacheMemoryContext itself in
favor of some more specific context in each case? That would make it
a lot clearer where to look for leaks -- or efficiencies.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-03-13 20:56:56 | Re: hyrax vs. RelationBuildPartitionDesc |
| Previous Message | Robert Haas | 2019-03-13 20:38:59 | Re: hyrax vs. RelationBuildPartitionDesc |