Re: Performance issue in foreign-key-aware join estimation
От | David Rowley |
---|---|
Тема | Re: Performance issue in foreign-key-aware join estimation |
Дата | |
Msg-id | CAKJS1f-wWz6mkn1ccYD5d4YY1gUSaak6vS=W_5GOQ3zU_LSkzQ@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 |
On Sat, 9 Mar 2019 at 08:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Setting the CF entry to WOA for now. I wonder though if we should > just push it out to v13 immediately --- are you intending to do more > with it in the near future? Thanks a lot for going over this and providing feedback. I put the patch out there mostly to see if such a thing is something we might want, and it's good to see no objections to the idea. I didn't want to waste too much time if there was going to be some serious objections to the idea. This is something I'd like to look into for v13. I think it'll be much easier to do if we can get your List reimplementation patch in first. That's going to allow list_nth on PlannerInfo->eq_classes to work quickly and will remove the need for having to build an array to store the classes, and as you mention, RelOptInfo could store a Bitmapset to store which ECs have members for this rel. I've modified the CF entry to target v13. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: