From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cost overestimation of foreign JOIN |
Date: | 2020-11-30 17:38:31 |
Message-ID: | 1272904.1606757911@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> writes:
> Maybe it is needed to swap lines 2908 and 2909 (see attachment)?
No; as explained in the comment immediately above here, we're assuming
that the join conditions will be applied on the cross product of the
input relations.
Now admittedly, that's a worst-case assumption, since it amounts to
expecting that the remote server will do the join in the dumbest
possible nested-loop way. If the remote can use a merge or hash
join, for example, the cost is likely to be a lot less. But it is
not the job of this code path to outguess the remote planner. It's
certainly not appropriate to invent an unprincipled cost estimate
as a substitute for trying to guess that.
If you're unhappy with the planning results you get for this,
why don't you have use_remote_estimate turned on?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-11-30 17:57:09 | Re: Autovacuum on partitioned table (autoanalyze) |
Previous Message | Alexey Kondratov | 2020-11-30 17:34:21 | Re: Notes on physical replica failover with logical publisher or subscriber |