Re: Damage control for planner's get_actual_variable_endpoint() runaway - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Damage control for planner's get_actual_variable_endpoint() runaway
Date
Msg-id 3122555.1669044748@sss.pgh.pa.us
Whole thread Raw
In response to Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Damage control for planner's get_actual_variable_endpoint() runaway
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Is there any reason to tie this into page costs? I'd be more inclined
> to just make it a hard limit on the number of pages. I think that
> would be more predictable and less prone to surprising (bad) behavior.

Agreed, a simple limit of N pages fetched seems appropriate.

> And to be honest I would be inclined to make it quite a small number.
> Perhaps 5 or 10. Is there a good argument for going any higher?

Sure: people are not complaining until it gets into the thousands.
And you have to remember that the entire mechanism exists only
because of user complaints about inaccurate estimates.  We shouldn't
be too eager to resurrect that problem.

I'd be happy with a limit of 100 pages.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Next
From: Robert Haas
Date:
Subject: Re: perform_spin_delay() vs wait events