On Thu, Feb 6, 2014 at 3:39 AM, Marti Raudsepp <ma...@juffo.org> wrote: > On Thu, Feb 6, 2014 at 5:31 AM, Robert Haas <robertmh...@gmail.com> wrote: >> Hmm, sounds a little steep. Why is it so expensive? I'm probably >> missing something here, because I would have thought that planner >> support for partial sorts would consist mostly of considering the same >> sorts we consider today, but with the costs reduced by the batching. > > I guess it's because the patch undoes some optimizations in the > mergejoin planner wrt caching merge clauses and adds a whole lot of > code to find_mergeclauses_for_pathkeys. In other code paths the > overhead does seem to be negligible. > > Notice the removal of: > /* Select the right mergeclauses, if we didn't already */ > /* > * Avoid rebuilding clause list if we already made one; > * saves memory in big join trees... > */
Yeah, I noticed that. My feeling is that those optimizations got put in there because someone found them to be important, so I'm skeptical about removing them. It may be that having the capability to do a partial sort makes it seem worth spending more CPU looking for merge joins, but I'd vote for making any such change a separate patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers