| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 21:24:35 |
| Message-ID: | 20190313212435.mtmpnndiynecbv7x@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-03-13 17:10:55 -0400, Tom Lane wrote:
> There's already a mechanism in there to suppress child contexts after
> 100 or so, which would almost inevitably kick in on the relcache if we
> did this. So I don't believe we'd have a problem with the context dumps
> getting too long --- more likely, the complaints would be the reverse.
Well, that's two sides of the same coin.
> Having said that, I do agree that CacheMemoryContext is too much of an
> undifferentiated blob right now, and splitting it up seems like it'd be
> good for accountability. I'd definitely be +1 for a catcache vs. relcache
> vs. other caches split.
That'd make a lot of sense.
> You could imagine per-catcache contexts, too.
> The main limiting factor here is that the per-context overhead could get
> excessive.
Yea, per relcache entry contexts seem like they'd get really expensive
fast. Even per-catcache seems like it might be noticable additional
overhead for a new backend.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-03-13 21:41:36 | Re: [HACKERS] Block level parallel vacuum |
| Previous Message | Tom Lane | 2019-03-13 21:10:55 | Re: hyrax vs. RelationBuildPartitionDesc |