Message-ID: <5B442A40.2040903@lab.ntt.co.jp>
Date: Tue, 10 Jul 2018 12:38:40 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with
 partition
 wise join enabled.
References: 
 <CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com>
 <CAFjFpRfGL9w-4C5N-ioaG3m+iheC1ey7_RMZ4vJijGn=wWJyxw@mail.gmail.com>
 <5AFD6580.5090308@lab.ntt.co.jp> <5AFE81CC.8000508@lab.ntt.co.jp>
 <5B17C5EC.1090602@lab.ntt.co.jp>
 <CAFjFpRffA-BfL0RXcUVLLbcOBF1ie7oObTB-RE2q_o45X1HTYg@mail.gmail.com>
 <5B1E5071.1000704@lab.ntt.co.jp> <5B23A964.9020800@lab.ntt.co.jp>
 <5B28FB19.3090809@lab.ntt.co.jp>
 <CAFjFpRedQBySj5Vm-eq+gATP6sqJJfXzPrV+Ld+K6DnaOGkFAQ@mail.gmail.com>
 <5B362B38.2000103@lab.ntt.co.jp>
 <CAFjFpRf55MT-9NnaRwp0wkDUTuwb++UA_un9Twai=qNVePh-TQ@mail.gmail.com>
 <5B3CB833.4040005@lab.ntt.co.jp>
 <CAFjFpRevODMmZ8MF3oLsXr9mSH9-mWC_fxmPWTYCSqHVr_Zwqg@mail.gmail.com>
 <5B3F4BAA.3050601@lab.ntt.co.jp>
 <CAFjFpRf2vd0C6B8g1TmpJN8RkPECgZy8iGe9UYZTy9EWu1eL2Q@mail.gmail.com>
 <5B4340E9.3030707@lab.ntt.co.jp>
 <CAFjFpRcwrESJBDkmm1kvtV234nkw=dr9nJ=RWJ4pmsVQqF4avg@mail.gmail.com>
 <5B434886.9010107@lab.ntt.co.jp>
 <CAFjFpRf-t_dM=qirB5+95wT1hSCLs8mQqbfRSKP=xUuhnOhbOQ@mail.gmail
 .com>
In-Reply-To: 
 <CAFjFpRf-t_dM=qirB5+95wT1hSCLs8mQqbfRSKP=xUuhnOhbOQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

(2018/07/09 20:43), Ashutosh Bapat wrote:
>>
>> I don't have any numbers right now, so that is nothing but a concern. But as
>> I said in a previous email, in the approach I proposed, we don't need to
>> spend extra cycles where partitioning is not involved.  I think that is a
>> good thing in itself.  No?
>
> At the cost of having targetlist being type inconsistent. I don't have
> any testcase either to show that that's a problem in practice. So,
> it's a trade-off of a concern vs concern.

As I said before, I don't see any issue in having such a targetlist, but 
I might be missing something, so I'd like to discuss a bit more about 
that.  Could you tell me the logic/place in the PG code where you think 
the problem might occur.  (IIRC, you mentioned something about that 
before (pathkeys? or index-only scans?), but sorry, I don't understand 
that.)

> Apart from that, in your approach there are extra cycles spent in
> traversing the targetlist to add ConvertRowtypeExpr, albeit only when
> there is a whole-row expression in the targetlist, when creating
> plans. That's not there in my patch.

Right.  That's unfortunate, but I think that that would be still better 
than needing to spent extra cycles where partitioning is not involved. 
And ISTM that the traversing cost is not that large compared to the cost 
we pay before that for query planning for a partitionwise join.

Best regards,
Etsuro Fujita