Re: Reducing relcache memory usage 2: shrink sizeof(RelationData) - Mailing list pgsql-hackers

From David Geier
Subject Re: Reducing relcache memory usage 2: shrink sizeof(RelationData)
Date
Msg-id e8c52d3a-b35b-4351-9896-12310323e465@googlemail.com
Whole thread
In response to Re: Reducing relcache memory usage 2: shrink sizeof(RelationData)  (David Geier <geidav.pg@gmail.com>)
List pgsql-hackers
>>> - 0005: Replaces the embedded partition key, descriptors, partition
>>> qual, validity flag, and memory contexts with one lazily allocated
>>> RelationPartitionInfo pointer.
>>> => sizeof(RelationData) == 264 bytes

Since patch set v2, this happens in patch 0006. All patches moved by 1
because I added a new patch 0001 (use SLAB context for all RelationData
objects).

>> I haven't worked on partitioning, so I'm not fully confident that this
>> has sufficiently low additional overhead to be worth applying.
> 
> I'll run a partitioned pgbench and report if I could measure any
> regressions.

I ran pgbench with 1000 partitions and scale factor 1 to put maximum
pressure on planning which I assumed uses the relcache most:

pgbench -i -s 1 --partitions=1000 postgres
pgbench -c 1 -j 1 -T 60 -S -M simple postgres

I ran against master and my patch, while having turbo boost, frequency
scaling, CPU idle states, ASLR and hyper threading disabled. I used a
single client to further stabilize results. The runs are still a little
bit noisy but FWICS don't show a regression.

 TPS master | TPS patched
------------+------------
  46,633    |   46,488
  45,560    |   46,437
  46,445    |   45,866

I've also attached v3 which is v2 rebased on latest master. No other
changes.

--
David Geier
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
Next
From: Kirill Reshke
Date:
Subject: Re: pg_dump/restore failure (dependency?) on BF serinus