From: Amit Kapila
> Okay, I can revert this work to avoid that risk but it would be great
> if you can share your thoughts on what alternative design do you have
> in mind, and or how it should be better implemented? Regarding
> performance overhead, it is for partitioned tables with a large numbe
From: Robert Haas
> Yeah, exactly. I don't think it's super-easy to understand exactly how
> to make that work well for something like this. It would be easy
> enough to set a flag in the relcache whose value is computed the first
> time we need it and is then consulted every time after that, and
From: Tom Lane
> Possibly-crazy late-night idea ahead:
>
> IIUC, we need to know a global property of a partitioning hierarchy:
> is every trigger, CHECK constraint, etc that might be run by an INSERT
> parallel-safe? What we see here is that reverse-engineering that
> property every time we nee
From: Robert Haas
> The amount of code isn't the issue. I'd rather expend a little more
> code and solve the problem in a better way.
Reading your reply to Andres-san, I feel sympathy about your attitude. Maybe
we should outline the (rough) design first, discuss/guess its complexity, and
ask f
From: Robert Haas
> On Wed, Mar 24, 2021 at 12:48 AM Andres Freund
> wrote:
> > Although this specific hack doesn't seem too terrible to me. If you
> > execute a parallel insert the likelihood to end up not needing an xid is
> > pretty low. Implementing it concurrently does seem like it'd end up
Hello Tom-san, Robert-san, Andres-san, others,
I've just started the following thread.
Parallel INSERT SELECT take 2
https://www.postgresql.org/message-id/TYAPR01MB29905A9AB82CC8BA50AB0F80FE709%40TYAPR01MB2990.jpnprd01.prod.outlook.com
I'm worried that this might not be the right time to ask th
