From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: no partition pruning when partitioning using array type |
Date: | 2018-07-11 04:34:47 |
Message-ID: | 39c7f34f-f888-ac78-a2bc-a741bddbc4c9@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/07/11 13:12, Alvaro Herrera wrote:
> On 2018-Jul-11, Amit Langote wrote:
>
>> What's the solution here then? Prevent domains as partition key?
>
> Maybe if a domain is used in a partition key somewhere, prevent
> constraints from being added?
Maybe, but I guess you mean only prevent adding such a constraint
after-the-fact.
If a domain has a constraint before creating any partitions based on the
domain, then partition creation command would check that the partition
bound values satisfy those constraints.
> Another thing worth considering: are you prevented from dropping a
> domain that's used in a partition key? If not, you get an ugly message
> when you later try to drop the table.
Yeah, I was about to write a message about that. I think we need to teach
RemoveAttributeById, which dependency.c calls when dropping the
referencing domain with cascade option, to abort if the attribute passed
to it belongs to the partition key of the input relation.
I tried that in the attached, but not sure about the order of messages
that appear in the output of DROP DOMAIN .. CASCADE. It contains a NOTICE
message followed by an ERROR message.
Thanks,
Amit
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Prevent-RemoveAttributeById-from-dropping-partiti.patch | text/plain | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-07-11 05:32:53 | Re: patch to allow disable of WAL recycling |
Previous Message | Amit Khandekar | 2018-07-11 04:34:29 | Re: Concurrency bug in UPDATE of partition-key |