On Tue, 30 Mar 2021 at 02:27, Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Sat, Mar 27, 2021 at 11:44 AM Andy Fan <zhihui.fan1...@gmail.com> wrote: > > > > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> Thanks for the patch. After a short look through it I'm a bit confused > >> and wanted to clarify, now uniquekeys list could contain both Expr and > >> EquivalenceClass? > > > > > > Yes, That's because I don't want to create a new EquivalenceClass (which > > would make the PlannerInfo->eq_classes longer) if we don't have > > one , then I just used one Expr instead for this case. > > However during the > > test, I found some EquivalenceClass with only 1 EquivalenceMember > > unexpectedly. > > > > Pathkeys may induce single member ECs. Why UniqueKeys are an exception?
I doubt that it should be. get_eclass_for_sort_expr() makes single-member ECs for sorts. I imagine the UniqueKey stuff should copy that... However, get_eclass_for_sort_expr() can often dominate the planning effort in queries to partitioned tables with a large number of partitions when the query has an ORDER BY. Perhaps Andy is trying to sidestep that issue? I mentioned a few things in [1] on what I think about this. David [1] https://www.postgresql.org/message-id/CAApHDvoDMyw=htuw-258yqnk4bhw6cpguju_gzbh4x+rnoe...@mail.gmail.com
