Re: How to retain lesser paths at add_path()?
От | Robert Haas |
---|---|
Тема | Re: How to retain lesser paths at add_path()? |
Дата | |
Msg-id | CA+TgmoY7wy-1yXNNLkR9oBfU_T_eg_sixcWdBNNZvQ7ZV8fD9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How to retain lesser paths at add_path()? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: How to retain lesser paths at add_path()?
Re: How to retain lesser paths at add_path()? |
Список | pgsql-hackers |
On Wed, Jul 31, 2019 at 11:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > What you'd want to do for something like the above, I think, is to > have some kind of figure of merit or other special marking for paths > that will have some possible special advantage in later planning > steps. Then you can teach add_path that that's another dimension it > should consider, in the same way that paths with different sort orders > or parallizability attributes don't dominate each other. Yeah, but I have to admit that this whole design makes me kinda uncomfortable. Every time somebody comes up with a new figure of merit, it increases not only the number of paths retained but also the cost of comparing two paths to possibly reject one of them. A few years ago, you came up with the (good) idea of rejecting some join paths before actually creating the paths, and I wonder if we ought to try to go further with that somehow. Or maybe, as Peter Geoghegan, has been saying, we ought to think about planning top-down with memoization instead of bottom up (yeah, I know that's a huge change). It just feels like the whole idea of a list of paths ordered by cost breaks down when there are so many ways that a not-cheapest path can still be worth keeping. Not sure exactly what would be better, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: