| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, keisuke(dot)kuroda(dot)3862(at)gmail(dot)com, tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp, pgsql-hackers(at)lists(dot)postgresql(dot)org, amitlangote09(at)gmail(dot)com, tatsuhito(dot)kasahara(dot)rd(at)hco(dot)ntt(dot)co(dot)jp |
| Subject: | Re: Huge memory consumption on partitioned table with FKs |
| Date: | 2020-12-01 02:38:05 |
| Message-ID: | CADkLM=cTt_8Fg1Jtij5j+QEBOxz9Cuu4DiMDYOwdtktDAKzuLw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> I think this can be solved easily in the patch, by having
> ri_BuildQueryKey() compare the parent's fk_attnums to the parent; if
> they are equal then use the parent's constaint_id, otherwise use the
> child constraint. That way, the cache entry is reused in the common
> case where they are identical.
>
Somewhat of a detour, but in reviewing the patch for Statement-Level RI
checks, Andres and I observed that SPI made for a large portion of the RI
overhead.
Given that we're already looking at these checks, I was wondering if this
might be the time to consider implementing these checks by directly
scanning the constraint index.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tsunakawa.takay@fujitsu.com | 2020-12-01 02:46:07 | RE: [Patch] Optimize dropping of relation buffers using dlist |
| Previous Message | Ajin Cherian | 2020-12-01 02:25:47 | Re: [HACKERS] logical decoding of two-phase transactions |