From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | Re: Separate memory contexts for relcache and catcache |
Date: | 2024-11-12 10:26:39 |
Message-ID: | CAExHW5skNdLG-kDiKe5k0EHUjc9xumjogHOWtEJKgS_xMB2Vcg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 12, 2024 at 2:57 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Mon, 2024-11-11 at 17:05 +0530, Ashutosh Bapat wrote:
> > It will be good
> > to move ahead with the ones we all agree for now. Looking at all the
> > emails, those will be CatCacheContext,
> > RelCacheContext, PlanCacheContext, TypCacheContext.
>
> I'm not sure we have consensus on all of those yet. Andres's concern,
> IIUC, is that the additional memory contexts will cause additional
> fragmentation.
>
> I believe we have a rough consensus that CatCacheContext and
> RelCacheContext are wanted, but we're trying to find ways to mitigate
> the fragmentation.
The totals (free_bytes, total_bytes, used_bytes) of memory contexts
separated from CacheMemoryContext and those without separate are
(35968, 540672, 504704) vs (75448,524288,448840). There's about 20K
increased in used_bytes and total_bytes. And we guess/know that that
increase is because of fragmentation. Am I right? But I don't find any
reference to what load Andres ran which resulted in this state [1]. So
can not make a judgement of whether that increase represents a typical
case or not.
I experimented with the plan cache context. I created 1000 tables
using Melih's [2] queries. But moved them into a single partitioned
table.
With no prepared statement
#SELECT name, count(*), pg_size_pretty(sum(total_bytes)) as
total_bytes, sum(total_nblocks) as total_nblocks,
pg_size_pretty(sum(free_bytes)) free_by
tes, sum(free_chunks) as free_chunks, pg_size_pretty(sum(used_bytes))
used_bytes from pg_get_backend_memory_contexts() where name like
'CachedPlan%' or name = 'PlanCacheContext' group by name;
name | count | total_bytes | total_nblocks | free_bytes |
free_chunks | used_bytes
------------------+-------+-------------+---------------+------------+-------------+------------
PlanCacheContext | 1 | 8192 bytes | 1 | 7952 bytes |
0 | 240 bytes
(1 row)
With 10 prepared statement each selecting from the partitioned table
#SELECT format('prepare all_tables_%s as SELECT count(*) FROM test',
g.i) from generate_series(1, 10) g(i); \gexec
#SELECT name, count(*), pg_size_pretty(sum(total_bytes)) as
total_bytes, sum(total_nblocks) as total_nblocks,
pg_size_pretty(sum(free_bytes)) free_bytes, sum(free_chunks) as
free_chunks, pg_size_pretty(sum(used_bytes)) used_bytes from
pg_get_backend_memory_contexts() where name like 'CachedPlan%' or name
= 'PlanCacheContext' group by name;
name | count | total_bytes | total_nblocks | free_bytes |
free_chunks | used_bytes
------------------+-------+-------------+---------------+------------+-------------+------------
CachedPlanQuery | 10 | 40 kB | 30 | 17 kB |
0 | 23 kB
CachedPlanSource | 10 | 20 kB | 20 | 3920 bytes |
0 | 16 kB
PlanCacheContext | 1 | 8192 bytes | 1 | 7952 bytes |
0 | 240 bytes
(3 rows)
After executing all those 10 statements
#SELECT format('execute all_tables_%s', g.i) from generate_series(1,
10) g(i); \gexec
#SELECT name, count(*), pg_size_pretty(sum(total_bytes)) as
total_bytes, sum(total_nblocks) as total_nblocks,
pg_size_pretty(sum(free_bytes)) free_bytes, sum(free_chunks) as
free_chunks, pg_size_pretty(sum(used_bytes)) used_bytes from
pg_get_backend_memory_contexts() where name like 'CachedPlan%' or name
= 'PlanCacheContext' group by name;
name | count | total_bytes | total_nblocks | free_bytes |
free_chunks | used_bytes
------------------+-------+-------------+---------------+------------+-------------+------------
CachedPlan | 10 | 20 MB | 124 | 9388 kB |
28 | 11 MB
CachedPlanQuery | 10 | 40 kB | 30 | 17 kB |
0 | 23 kB
CachedPlanSource | 10 | 20 kB | 20 | 3920 bytes |
0 | 16 kB
PlanCacheContext | 1 | 8192 bytes | 1 | 7952 bytes |
0 | 240 bytes
(4 rows)
PlanCacheContext is never used for actual planned statements. In fact
I am not sure whether those 8K bytes it's consuming are real or just
context overhead. The real memory is used from CachedPlan* contexts
which are created and destroyed for each prepared statement.
The only use of the shell context is to be able to query memory
context statistics of cached plans, in case we change the names of
contexts for individual planned queries in future.
SELECT name, count(*), pg_size_pretty(sum(total_bytes)) as
total_bytes, sum(total_nblocks) as total_nblocks,
pg_size_pretty(sum(free_bytes)) free_bytes, sum(free_chunks) as
free_chunks, pg_size_pretty(sum(used_bytes)) used_bytes from
pg_get_backend_memory_contexts() where path @> (select path from
pg_get_backend_memory_contexts() where name = 'PlanCacheContext')
group by name;
So separating PlanCacheContext seems to have little use.
[1] https://www.postgresql.org/message-id/dywwv6v6vq3wfqyebypspq7kuez44tnycbvqjspgsqypuunbzn@mzixkn6g47y2
[2] https://www.postgresql.org/message-id/CAGPVpCTJWEQLt2eOSDGTDtRbQPUQ9b9JtZWro9osJubTyWAEMA@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-11-12 10:27:04 | Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY |
Previous Message | Zhijie Hou (Fujitsu) | 2024-11-12 10:19:51 | RE: Conflict detection for update_deleted in logical replication |