From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Updating row and width estimates in postgres_fdw |
Date: | 2020-02-12 16:17:30 |
Message-ID: | CAExHW5tjTOMGnYA6-Wz87YBsDqC4pAAB7OAq03h2Wt_x3P3zqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
In postgresGetForeignJoinPaths(), I see
/* Estimate costs for bare join relation */
estimate_path_cost_size(root, joinrel, NIL, NIL, NULL,
&rows, &width, &startup_cost, &total_cost);
/* Now update this information in the joinrel */
joinrel->rows = rows;
joinrel->reltarget->width = width;
This code is good as well as bad.
For a join relation, we estimate the number of rows in
set_joinrel_size_estimates() inside build_*_join_rel() and set the width of
the join when building the targetlist. For foreign join, the size estimates
may not be correct but width estimate should be. So updating the number of
rows looks good since it would be better than what
set_joinrel_size_etimates() might come up with but here are the problems
with this code
1. The rows estimated by estimate_path_cost_size() are better only when
use_remote_estimates is true. So, we should be doing this only when
use_remote_estimate is true.
2. This function gets called after local paths for the first pair for this
join have been added. So those paths are not being judged fairly and
perhaps we might be throwing away better paths just because the local
estimates with which they were created were very different from the remote
estimates.
A better way would be to get the estimates and setup fpinfo for a joinrel
in build_join_rel() and later add paths similar to what we do for base
relations. That means we split the current hook GetForeignJoinPaths into
two - one to get estimates and the other to setup fpinfo.
Comments?
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-02-12 16:22:58 | Re: Just for fun: Postgres 20? |
Previous Message | Shichao Jin | 2020-02-12 15:41:26 | Re: Memory-comparable Serialization of Data Types |