From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-25 01:26:08 |
Message-ID: | CAApHDvoSnkwhDdL20nPHUK26MECozyKk=2xYfSMS0CdNwTmE9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 24 Jun 2021 at 12:32, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> The overhead of taking these locks is pretty significant for
> partitioned tables with lots of partitions where only 1 of them
> survives run-time partition pruning. That's really terrible for
> people that want to PREPARE queries and just look up a single row from
> a single partition. That seems like a pretty big use case that we're
> just terrible at today.
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().
A lock would need to be taken on each partitioned table before we
prune for it. So if there was multi-level partitioning, we'd need to
lock the partitioned table, do pruning for that partitioned table,
then lock any sub-partitioned tables before doing pruning on those.
I don't immediately see why it couldn't be made to work, it's just
that it adds quite a lot of complexity to what's being done in
AcquireExecutorLocks(), which today is a very simple function.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiro Ikeda | 2021-06-25 01:33:23 | Re: Transactions involving multiple postgres foreign servers, take 2 |
Previous Message | Masahiro Ikeda | 2021-06-25 00:53:52 | Re: Transactions involving multiple postgres foreign servers, take 2 |