Keith Fiske

Thank you for this fix. That was definitely an oversight, but just to let you know this will not work with native partitioning. See Issue #365. When you cascade removal...

That is potentially an issue yes. If the FK is created through the parent table and you cascade delete the FK on a child table, it deletes it for the...

Also noting that I would not add this feature back in until PG10 support is dropped later this year along with trigger-based partitioning potentially. Since then I could repurpose this...

If you try and detach a child table that has values referenced by another table's FK, that detach operation fails. See https://github.com/pgpartman/pg_partman/issues/294 That worked for that PR because the CASCADE...

> > I'm going to see if adding the FKs directly to the child tables via the template table is a possible workaround for this. > > I tried that,...

Apologies I am conflating two different FK issues here. Either way, I will be re-evaluating the handling of FKs in an upcoming release. I will definitely keep your ideas in...

This does almost sound a bit like IO saturation or possibly contention in shared_buffers. I know you stated that it doesn't appear to be the case, but might still be...

Did you have any further questions on this? Otherwise I will be closing this issue during my next review.

Hmm that is odd that the INSERT INTO ... SELECT ... didn't see the same slow-down as doing the batch mode. The entire reason for the batch mode was to...

So I'll leave this issue open for a while to see if anyone has any other suggestions, but @cj13579's two suggestions are really the only way I can think to...