Re: pg9.6 segfault using simple query (related to use fk for join estimates)
От | David Rowley |
---|---|
Тема | Re: pg9.6 segfault using simple query (related to use fk for join estimates) |
Дата | |
Msg-id | CAKJS1f9VMZGfPCDWeuLoD1rgvTr5JzGLh7vc4YWQCSDrmRCKbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg9.6 segfault using simple query (related to use fk for join estimates) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: pg9.6 segfault using simple query (related to use fk
for join estimates)
|
Список | pgsql-hackers |
On 4 May 2016 at 02:10, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > There are probably a few reasonably simple things we could do - e.g. ignore > foreign keys with just a single column, as the primary goal of the patch is > improving estimates with multi-column foreign keys. I believe that covers a > vast majority of foreign keys in the wild. > > If that's deemed insufficient, we'll have to resort to a more complex > improvement, perhaps something akin to the cache proposed in in the unijoin > patch. But if that's required, that's 9.7 material. I had thought that if we had a hashtable of rel OIDs which belong to relations with has_eclass_joins == true, then we could just skip foreign keys where the confrelid is not in the hashtable. Perhaps that could be optimised a bit more and we could have something akin to what predOK is for IndexOptInfo in ForeignKeyOptInfo which just gets set to true if the relation referenced by the foreign key is in the simple_rel_array. It's quite likely that if many foreign keys were used, then the query would have a great number of joins, and planning would be slow anyway. -- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: