Re: Damage control for planner's get_actual_variable_endpoint() runaway
От | Robert Haas |
---|---|
Тема | Re: Damage control for planner's get_actual_variable_endpoint() runaway |
Дата | |
Msg-id | CA+Tgmoa4WoKeXHW+=JEQ1XzzOCd-Bwe-wkZoVYN2qPD-kN+skg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Damage control for planner's get_actual_variable_endpoint() runaway (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Damage control for planner's get_actual_variable_endpoint() runaway
|
Список | pgsql-hackers |
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. Whether we can spend a lot of > time scanning the index without ever finding a tuple at all seems > hypothetical. Without more evidence of a real problem, I do not > wish to inject warts as horrid as this one into the index AM API. 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. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: