Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-09T11:35:34Z
Lists: pgsql-hackers
(2018/07/09 20:06), Ashutosh Bapat wrote:
> On Mon, Jul 9, 2018 at 4:33 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp>  wrote:
>>> As I said, we do spend cycles in that function testing whether a node
>>> is Aggref or not even when the query doesn't have aggregates or
>>> grouping OR spend cycles in testing whether a node is a PlaceHolderVar
>>> when the query doesn't produce any. So, I don't see any problem with
>>> spending a few cycles testing whether a node is ConvertRowtypeExpr or
>>> not when a ConvertRowtypeExpr is not in the query or command. That's
>>> not a huge performance trouble. I would be happy to change my mind, if
>>> you show me performance different with and without this patch in
>>> planning. I haven't seen any.
>>
>>
>> I have to admit that the case in [1] wouldn't affect the performance, but my
>> concern is that there might be some cases where the test affects
>> performance.
>
> What are those cases? Can you please provide any numbers supporting your claim?

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?

Best regards,
Etsuro Fujita


Commits

  1. Adjust EXPLAIN's output for disabled nodes

  2. Disable support for partitionwise joins in problematic cases.

  3. Rewrite the code that applies scan/join targets to paths.