Re: Partitionwise join fails under GEQO
От | Amit Langote |
---|---|
Тема | Re: Partitionwise join fails under GEQO |
Дата | |
Msg-id | CA+HiwqE20bfjgzrJiuddaU6uVdXYGxahr5o0u3m9MVsfsfLdtQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Partitionwise join fails under GEQO (Amit Langote <amitlangote09@gmail.com>) |
Список | pgsql-hackers |
On Thu, Oct 8, 2020 at 2:58 PM Amit Langote <amitlangote09@gmail.com> wrote: > On Wed, Oct 7, 2020 at 12:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes: > > > On Mon, Oct 5, 2020 at 11:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> ... we could avoid the growth in eclass members for large partition sets > > >> if we simply didn't store child eclass members, instead translating > > >> on-the-fly when we need to deal with child rels. I have a patch > > >> about half done, but it won't be possible to determine the true > > >> performance implications of that idea until it's all done. More > > >> later. > > +1 to this idea. We've seen mainly get_eclass_for_sort_expr() become > a bottleneck with large partition sets and getting rid of it would be > really great. > > [1] https://www.postgresql.org/message-id/CAApHDvrEXcadNYAAdq6RO0eKZUG6rRHXJGAbpzj8y432gCD9bA%40mail.gmail.com Oops, I linked this thread but forgot to write why. Well, I had meant to say that I had unsuccessfully tried to implement this idea as a PoC back when David had started the linked discussion to address the same problem. -- Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: