Re: [HACKERS] Linear vs. nonlinear planner cost estimates

On Wed, Dec 14, 2016 at 3:46 PM, Tom Lane wrote: > The really *critical* aspect of this, which could cost far more than a > few extra executions of a costing function, comes in if it damages > add_path's ability to prune inferior paths early. So we would not want > to simply

Re: [HACKERS] Linear vs. nonlinear planner cost estimates

Robert Haas writes: > On Wed, Dec 14, 2016 at 2:12 PM, Tom Lane wrote: >> I don't have a concrete proposal right now about how to fix this. The >> most expansive response would be to decorate every path with an explicitly >> nonlinear cost function,

Re: [HACKERS] Linear vs. nonlinear planner cost estimates

On Wed, Dec 14, 2016 at 2:12 PM, Tom Lane wrote: > I don't have a concrete proposal right now about how to fix this. The > most expansive response would be to decorate every path with an explicitly > nonlinear cost function, which would need to be able to report the cost > to

[HACKERS] Linear vs. nonlinear planner cost estimates

I've been looking into the problem reported here: https://www.postgresql.org/message-id/CAOfJSTwzQ7Fx6Yjeg9mFkMsM5OVKPoa=egkhcegdkr1twg8...@mail.gmail.com I can reproduce similar misbehavior with this test case: create table updates as select (-log(random()) * 10)::int as driver_id, now()