From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Deadlock risk while inserting directly into partition? |
Date: | 2021-06-28 12:08:31 |
Message-ID: | CAApHDvrS=VqKB3whKdzo78DzxvC9WN2GE1txthO1Vh73LU9bcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 28 Jun 2021 at 15:59, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> On Fri, Jun 25, 2021 at 10:26 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > I wonder, since we can't delay taking locks until after run-time
> > pruning due to being unable to invalidate cached plans, maybe instead
> > we could tag on any PartitionPruneInfo onto the PlannedStmt itself and
> > do the init plan run-time prune run during AcquireExecutorLocks().
>
> This is exactly what I was mulling doing when working on [1] some last
> year, after an off-list discussion with Robert (he suggested the idea
> IIRC), though I never quite finished writing a patch. I have planned
> to revisit this topic ("locking overhead in generic plans") for v15,
> now that we have *some* proposals mentioned in [1] committed to v14,
> so can look into this.
I thought about this only a little bit more from when I wrote the
above. I think it would require adding yet another stage of when we
do run-time pruning. It should be possible to do pruning when there's
GeneratePruningStepsContext.has_exec_param == true. However, I'm not
so sure that we could do GeneratePruningStepsContext.has_mutable_arg.
Evaluating the value for those requires some level of actual
execution. That's a pity as we'd still need to take a bunch of extra
locks in a case like: SELECT * FROM time_parted WHERE ts >= NOW() -
INTERVAL '1 hour';
I see the param values are fairly easily accessible a couple of levels
up from AcquireExecutorLocks() in GetCachedPlan().
> Anyway, do you agree with starting a thread to discuss possible
> approaches to attack this?
Agreed about the separate thread. We can discuss it further there.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-06-28 12:29:10 | pgindent run |
Previous Message | Daniel Gustafsson | 2021-06-28 11:57:24 | Re: Remove redundant initializations |