Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.
От | Etsuro Fujita |
---|---|
Тема | Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled. |
Дата | |
Msg-id | 5B442A40.2040903@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Expression errors with "FOR UPDATE" and postgres_fdw withpartition wise join enabled. (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: Expression errors with "FOR UPDATE" and postgres_fdw withpartition wise join enabled.
|
Список | pgsql-hackers |
(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
В списке pgsql-hackers по дате отправления: