(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