Horton

Re: hyrax vs. RelationBuildPartitionDesc

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-13T21:24:35Z
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

Commits

  1. Load relcache entries' partitioning data on-demand, not immediately.

  2. Prevent memory leaks associated with relcache rd_partcheck structures.

  3. Don't copy PartitionBoundInfo in set_relation_partition_info.

  4. Further reduce memory footprint of CLOBBER_CACHE_ALWAYS testing.

  5. Fix some oversights in commit 2455ab488.

  6. Defend against leaks into RelationBuildPartitionDesc.

  7. Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.