Hi Amit-san,
Thanks for the answer!
> If you only tested insert/update on the referencing table, I would've
> expected to see nothing in the result of that query, because the patch
> eliminates all use of SPI in that case. I suspect the CachedPlan*
> memory contexts you are seeing belong to some early activity in the
> session. So if you try the insert/update in a freshly started
> session, you would see 0 rows in the result of that query.
That's right.
CREATE PARTITION TABLE included in the test script(rep.sql) was using SPI.
In a new session, I confirmed that CachedPlan is not generated when only
execute INSERT.
# only execute INSERT
postgres=# INSERT INTO ps SELECT generate_series(1,4999);
INSERT 0 4999
postgres=#
postgres=# INSERT INTO pr SELECT i, i from generate_series(1,4999)i;
INSERT 0 4999
postgres=# SELECT name, sum(used_bytes) as bytes,
pg_size_pretty(sum(used_bytes)) FROM pg_backend_memory_contexts
WHERE name LIKE 'Cached%' GROUP BY name;
name | bytes | pg_size_pretty
------+-------+----------------
(0 rows) ★ No CachedPlan
> Hmm, the patch tries to solve a general problem that SPI plans are not
> being shared among partitions whereas they should be. So I don't
> think that it's necessarily specific to DELETE. Until we have a
> solution like the patch on this thread for DELETE, it seems fine to
> consider the other patch as a stopgap solution.
I see.
So this is a solution to the problem of using SPI plans in partitions,
not just DELETE.
I agree with you, I think this is a solution to the current problem.
Best Regards,
--
Keisuke Kuroda
NTT Software Innovation Center
keisuke.kuroda.3862@gmail.com
