Neil Conway <[EMAIL PROTECTED]> writes:
> Per recent discussion on -hackers, we should sometimes try to reorder
> the columns of the grouping clause to avoid redundant sorts. The
> optimizer is not currently capable of doing this, so this patch
> implements a simple hack in the analysis phase (transformGroupClause):
> if any subset of the GROUP BY clause matches a prefix of the ORDER BY
> list, that prefix is moved to the front of the GROUP BY clause.
I find this patch a tad inelegant. It seems like a confusing way to
think about the problem, and it also means that the routine is
effectively matching the sort clause and group clause twice --- once
in the code you added and once in the existing code.
The idea that I had about how the revised routine should work is
basically:
1. For each ORDER BY item:
1a. Find a matching GROUP BY item.
(Break out of loop if no match.)
1b. Add it to the output list with ORDER BY item's ordering op.
1c. Remove the matched item from the GROUP BY list.
2. For each remaining GROUP BY item:
2a. Add it to output list using default ordering op.
This might require a bit of code duplication from the two "add to output
list" steps, but I think it'd be a lot clearer. You could probably
avoid most of the code duplication by making a preliminary list of
TargetEntrys (findTargetlistEntry and the UNKNOWN->TEXT hack) before
applying the above steps. Or make a subroutine.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
