Re: Needless additional partition check in INSERT?

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Subject: Re: Needless additional partition check in INSERT?
Date: 2018-05-10 04:13:07
Message-ID: 06a68b44-9ddd-51d4-75a9-75fbead8ec0f@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018/05/10 12:55, David Rowley wrote:
> Hi,
>
> Scanning ExecInsert, it looks like there's a needless additional
> partition constraint check against the tuple. This should only be
> required if there's a before row INSERT trigger. The code block up
> one from the additional check tries to disable the check, but it goes
> ahead regardless, providing there's some other constraint.
>
> ExecFindPartition should have already located the correct partition
> and nothing should have changed in the absence of before row insert
> triggers, so it looks like we're fine to not bother re-checking.

I think you're right. So if we call ExecConstraints only because there
are other tuple constraints (rd_att->constr != NULL), then currently we
pass true for whether to check the partition constraint, irrespective of
the value of check_partition_constr. I guess 19c47e7c820 should have done
it the way your patch teaches it do to begin with.

The patch to ExecInsert looks good, but I think we also need to do the
same thing in CopyFrom.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-05-10 04:33:47 Re: Needless additional partition check in INSERT?
Previous Message Ashutosh Bapat 2018-05-10 04:04:33 Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.