From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: making update/delete of inheritance trees scale better |
Date: | 2021-04-01 02:09:09 |
Message-ID: | CA+HiwqHECHbFce6eeDqRxs5tUeQTFuE5-5CNmW+M_fCqkNv+kQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 1, 2021 at 12:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > On Tue, Mar 30, 2021 at 1:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Here's a v13 patchset that I feel pretty good about.
>
> > Thanks. After staring at this for a day now, I do too.
>
> Thanks for looking! Pushed after some more docs-fiddling and a final
> read-through. I think the only code change from v13 is that I decided
> to convert ExecGetJunkAttribute into a "static inline", since it's
> just a thin wrapper around slot_getattr(). Doesn't really help
> performance much, but it shouldn't hurt.
Thanks a lot.
> > ... The drop as partition count increases can
> > be attributed to the fact that with a generic plan, there are a bunch
> > of steps that must be done across all partitions, such as
> > AcauireExecutorLocks(), ExecCheckRTPerms(), per-result-rel
> > initializations in ExecInitModifyTable(), etc., even with the patched.
> > As mentioned upthread, [1] can help with the last bit.
>
> I'll try to find some time to look at that one.
>
> I'd previously been thinking that we couldn't be lazy about applying
> most of those steps at executor startup, but on second thought,
> ExecCheckRTPerms should be a no-op anyway for child tables.
Yeah, David did say that in that thread:
> So
> maybe it would be okay to not take a lock, much less do the other
> stuff, until the particular child table is stored into.
Note that the patch over there doesn't do anything about
AcquireExecutorLocks() bottleneck, as there are some yet-unsolved race
conditions that were previously discussed here:
Anyway, I'll post the rebased version of the patch that we do have.
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-04-01 02:28:56 | Re: multi-install PostgresNode fails with older postgres versions |
Previous Message | Masahiko Sawada | 2021-04-01 01:55:41 | Re: a misbehavior of partition row movement (?) |