| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Jim Finnerty <jfinnert(at)amazon(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: On disable_cost |
| Date: | 2019-11-01 17:04:06 |
| Message-ID: | 20191101170406.w6ybnafyvpxv2ltg@development |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 01, 2019 at 09:30:52AM -0700, Jim Finnerty wrote:
>re: coping with adding disable_cost more than once
>
>Another option would be to have a 2-part Cost structure. If disable_cost is
>ever added to the Cost, then you set a flag recording this. If any plans
>exist that have no disable_costs added to them, then the planner chooses the
>minimum cost among those, otherwise you choose the minimum cost path.
>
Yeah, I agree having is_disabled flag, and treat all paths with 'true'
as more expensive than paths with 'false' (and when both paths have the
same value then actually compare the cost) is probably the way forward.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-11-01 17:10:38 | Re: 64 bit transaction id |
| Previous Message | Tomas Vondra | 2019-11-01 16:59:50 | Re: pglz performance |