From: | Antonin Houska <ah(at)cybertec(dot)at> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw: another oddity in costing aggregate pushdown paths |
Date: | 2019-02-22 14:10:22 |
Message-ID: | 29503.1550844622@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> As mentioned in the near thread, I think there is another oversight in
> the cost estimation for aggregate pushdown paths in postgres_fdw, IIUC.
> When costing an aggregate pushdown path using local statistics, we
> re-use the estimated costs of implementing the underlying scan/join
> relation, cached in the relation's PgFdwRelationInfo (ie,
> rel_startup_cost and rel_total_cost). Since these costs wouldn't yet
> contain the costs of evaluating the final scan/join target, as tlist
> replacement by apply_scanjoin_target_to_paths() is performed afterwards.
> So I think we need to adjust these costs so that the tlist eval costs
> are included, but ISTM that estimate_path_cost_size() forgot to do so.
> Attached is a patch for fixing this issue.
I think the following comment in apply_scanjoin_target_to_paths() should
mention that FDWs rely on the new value of reltarget.
/*
* Update the reltarget. This may not be strictly necessary in all cases,
* but it is at least necessary when create_append_path() gets called
* below directly or indirectly, since that function uses the reltarget as
* the pathtarget for the resulting path. It seems like a good idea to do
* it unconditionally.
*/
rel->reltarget = llast_node(PathTarget, scanjoin_targets);
--
Antonin Houska
https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2019-02-22 14:12:55 | INSERT ... OVERRIDING USER VALUE vs GENERATED ALWAYS identity columns |
Previous Message | Magnus Hagander | 2019-02-22 14:03:39 | Re: Remove Deprecated Exclusive Backup Mode |