| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, andrew(at)ankane(dot)org |
| Subject: | Re: On disable_cost |
| Date: | 2024-08-23 17:42:53 |
| Message-ID: | 2269318.1724434973@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 23, 2024 at 1:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It looks like amcostestimate could change the path's disabled_nodes
>> count, since that's set up before invoking amcostestimate. I guess
>> it could be set to INT_MAX to have a comparable solution to before.
> It's probably better to add a more modest value, to avoid overflow.
> You could add a million or so and be far away from overflow while
> presumably still being more disabled than any other path.
But that'd only matter if the path survived its first add_path
tournament, which it shouldn't. If it does then you're at risk
of the same run-time failure reported here.
(Having said that, you're likely right that "a million or so"
would be a safer choice, since it doesn't require the assumption
that the path fails instantly.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2024-08-23 18:18:32 | Re: On disable_cost |
| Previous Message | Robert Haas | 2024-08-23 17:37:53 | Re: On disable_cost |