Thank you, > In any case, it seems like a bad idea to me to conflate > distinct-ness with ordering, so I don't like what you did to > PathKeys.
Hmm, that sounds quite resonable in general. But the conflation is already found in grouping_planner to some extent. The name distinct_pathkey itself asserts that it is the ordering used for distinct. And actually is used for sorting if hashed-distinct is not selected. Plus, these modifications in grouping_planner is required by the patch for pathkeys.c to be effective. I suppose the main cause of nastiness of the patch for grouping_planner comes from the adheration of the usage of the variable for path uniqueness with the existent code. The additional members to Plan, say, pathkeys and ordered could help the code to look less ugly by taking in the related code currently appears nakedly in grouping_planner into make(or generate)_xxxxplan() functions. Although the new attributes somewhat look out of place.. > > However, if the index is unique, wouldn't > > scanning the index produce data that actually satisfies the longer sort > > key? It doesn't matter what the values of c,d are if there are no > > duplicates in the a,b columns. So maybe as a separate patch, we could > > look at claiming that a unique index satisfies the entire query_pathkeys > > if it matches the first N columns of that. > > That would be really spiffy. # Putting aside the trueness of the assumption for unique-index # and pathkeys. The "expanded" sufficiency check can be archieved by involving 'unique-indexed' attribute for pathkeys_contained_in(),say pathkeys_satisfies(pathkeys, pathkeys, is_uniq), but finally could have no effect without some extent of assist in the process in grouping_planner like my preveous patch to be in effect, I believe. I'll try to rewrite the path to be as following considering less conflating lookings in grouping_planner. - is_unique and pathkeys is added to the type Path. (umm...) - create function like pathkeys_satisfies(check_pathkeys, pathkeys, isuniq) or path_ordered_by(pathkeys, path) as needed. - Plan will be set ordered and pathkeys derived from source path and its process and grouping_planner consults it to deceide whether to do sort (to hide the currently naked code). - Add check for NULLuble columns :-) regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
