Re: Damage control for planner's get_actual_variable_endpoint() runaway
От | Tom Lane |
---|---|
Тема | Re: Damage control for planner's get_actual_variable_endpoint() runaway |
Дата | |
Msg-id | 3348462.1669072672@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Damage control for planner's get_actual_variable_endpoint() runaway (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Damage control for planner's get_actual_variable_endpoint() runaway
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Nov 21, 2022 at 5:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think we should content ourselves with improving the demonstrated >> case, which is where we're forced to do a lot of heap fetches due >> to lots of not-all-visible tuples. > All right. I've been bitten by this problem enough that I'm a little > gun-shy about accepting anything that doesn't feel like a 100% > solution, but I admit that the scenario I described does seem a little > bit far-fetched. > I won't be completely shocked if somebody finds a way to hit it, though. Well, if we see a case where the time is indeed spent completely within the index AM, then we'll have to do something more or less like what Simon sketched. But I don't want to go there without evidence that it's a live problem. API warts are really hard to get rid of once instituted. regards, tom lane
В списке pgsql-hackers по дате отправления: