Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, 11 Apr 2019 at 17:40, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I tweaked this patch some more (sorry):
> - remove "currently" since that's not expected to be changed (right?);

Seems like a good idea. I think the way we exclude inheritance child
relations will never scale well. Other improvements that we'll see
will most likely be as a consequence of speeding up declarative
partitioning. For example the planner improvements in PG12 just did
that for UPDATE/DELETE.

> - remove "especially";

I think that likely needs to be kept for the PG11 version. I was
hoping it was stop a casual tester testing a SELECT and seeing that
it's not so bad only to find later that UPDATE/DELETE OOMs.

> - refer to "partition hierarchies" not "partitioning hierarchies";

fine

> - rewrite bit about "When partition pruning is not possible"

fine.

> Also, I noticed awhile ago while grepping for "probably be fixed in future
> releases" that some items under ddl-inherit-caveats are actually possible for
> relkind=p partitions in v11. I assume those will never be implemented for
> inheritence partitioning, so I propose another update to docs (if preferred,
> I'll bring up on a new thread).

Not sure about that. It may be very simple to implement if we one day
get global indexes. It may just be a matter of pointing all the tables
at the same index and letting the wonders of global indexes handle all
the hard stuff. I'm not that excited about removing that. I'd be
equally excited about adding the text if it wasn't already there and
you were proposing to add it.

> - unique constraints on parent table;
> - FK constraints on parent table;
>
> Note that FK constraints *referencing* a partitiond table are possible in v12
> but not in v11. So if there's any finer-grained update to documentation of the
> individual limitations, it'd need to be tweaked for back branches (v10 and 11).

Don't we just need to remove or update:

<listitem>
<para>
While primary keys are supported on partitioned tables, foreign
keys referencing partitioned tables are not supported. (Foreign key
references from a partitioned table to some other table are supported.)
</para>
</listitem>

I didn't follow this work, but on testing, I see the foreign key does
not CASCADE when doing DETACH PARTITION, it errors instead. Perhaps
that's worth a mention here.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services