Re: Optimise default partition scanning while adding new partition

On Thu, Sep 14, 2017 at 4:03 AM, Jeevan Ladhe
<jeevan(dot)ladhe(at)enterprisedb(dot)com> wrote:
> Thanks Amit for reviewing.
>> Patch looks fine to me. By the way, why don't we just say "Can we skip
>> scanning part_rel?" in the comment before the newly added call to
>> PartConstraintImpliedByRelConstraint()? We don't need to repeat the
>> explanation of what it does at the every place we call it.
>
> I have changed the comment.
> PFA.

I'm probably missing something stupid, but why does this happen?

ALTER TABLE list_parted2 ATTACH PARTITION part_7 FOR VALUES IN (7);
-INFO: partition constraint for table "list_parted2_def" is implied
by existing constraints
ERROR: partition constraint is violated by some row

Based on the regression test changes made up higher in the file, I'd
expect that line to be replaced by two lines, one for
list_parted2_def_p1 and another for list_parted2_def_p2, because at
this point, list_parted2_def is a partitioned table with those two
children, and they seem to have appropriate constraints.

list_parted2_def_p1 has
Check constraints:
"check_a" CHECK (a = ANY (ARRAY[21, 22]))

list_parted2_def_p2 has
Check constraints:
"check_a" CHECK (a = ANY (ARRAY[31, 32]))

Well, if a is 21 or 22 for the first, or 31 or 32 for the second, then
it's not 7. Or so I would think.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company