Re: allowing extensions to control planner behavior
От | Robert Haas |
---|---|
Тема | Re: allowing extensions to control planner behavior |
Дата | |
Msg-id | CA+TgmoY4yBRawLY-u0GM6aW7f0N4W8RU8WsZRb5+qhpWWfmZcQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: allowing extensions to control planner behavior (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: allowing extensions to control planner behavior
|
Список | pgsql-hackers |
On Wed, Aug 28, 2024 at 4:29 PM Jeff Davis <pgsql@j-davis.com> wrote: > Preserving a path for the right amount of time seems like the primary > challenge for most of the use cases you raised (removing paths is > easier than resurrecting one that was pruned too early). If we try to > keep a path around, that implies that we need to keep parent paths > around too, which leads to an explosion if we aren't careful. > > But we already solved all of that for pathkeys. We keep the paths > around if there's a reason to (a useful pathkey) and there's not some > other cheaper path that also satisfies the same reason. But we've already solved it for this case, too. This is exactly what incrementing disabled_nodes does. This very recently replaced what we did previously, which was adding disable_cost to the cost of every path. Either way, you just need a hook that lets you disable the paths that you don't prefer. Once you do that, add_path() takes care of the rest: disabled paths lose to non-disabled paths, and disabled paths lose to more expensive disabled paths. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: