Andrew Gierth <> writes:
> So in the grouping sets patch post, I said:
> There is one current weakness which I don't see a good solution for:
> the planner code still has to pick a single value for group_pathkeys
> before planning the input path.  This means that we sometimes can't
> choose a minimal set of sorts, because we may have chosen a sort
> order for a grouping set that should have been hashed,

> Of course there is one good solution, which is to have query_planner
> take a set of acceptable output sort orders rather than just a single
> one.

> How wild an idea is this?

It's been on my to-do list for years, see e.g.
The idea wouldn't have been very helpful before the upper planner got
path-ified, but now the only stumbling block is a shortage of round tuits.

> I guess a possible hazard is an increase in
> the number of possible mergejoin paths to consider.

Yeah, you'd have to keep an eye on possible growth in planning time, but
I feel optimistic that it wouldn't be a big problem.  Usually when you
hear me bitching about planning time growth from some random idea, it's
because the extra cycles would be spent all the time but seldom result in
a win.  But with something like this, extra cycles would be spent only
when there was a demonstrable reason for the investigation, i.e., possible
savings at a grouping or windowing step.  And it wouldn't be a wild-goose
chase but a targeted investigation of directly-relevant sort orders.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to