Re: Performance issue in foreign-key-aware join estimation
От | David Rowley |
---|---|
Тема | Re: Performance issue in foreign-key-aware join estimation |
Дата | |
Msg-id | CAKJS1f-KgonusPcWctDjTCWkw4dAxa98VP6YVr9uFwukGf2X4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance issue in foreign-key-aware join estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Performance issue in foreign-key-aware join estimation
|
Список | pgsql-hackers |
Thanks for having a hack at this. On Fri, 22 Mar 2019 at 10:10, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm unsure how hard we should push to get something like this into v12. > I'm concerned that its dependency on list_nth might result in performance > regressions in some cases; it's a lot easier to believe that this will > be mostly-a-win with the better List infrastructure we're hoping to get > into v13. If you want to keep playing with it, OK, but I'm kind of > tempted to shelve it for now. Yeah, mentioned a similar concern above. The best I could come up with to combat it was the list_skip_forward function. It wasn't particularly pretty and was only intended as a stop-gap until List become array-based. I think it should stop any regression. I'm okay with waiting until we get array based Lists, if you think that's best, but it's a bit sad to leave this regression in yet another major release. However, there's always a danger we find some show-stopper with your list reimplementation patch, in which case I wouldn't really like to be left with list_skip_forward() in core. If there's any consensus we want this for v12, then I'll happily look over your patch, otherwise, I'll look sometime before July. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: