Teaching query_planner to handle multiple sort orders?

Started by Andrew Gierthabout 9 years ago3 messages
#1Andrew Gierth
andrew@tao11.riddles.org.uk

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? I guess a possible hazard is an increase in
the number of possible mergejoin paths to consider. What other possible
issues are there?

--
Andrew (irc:RhodiumToad)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Gierth (#1)
Re: Teaching query_planner to handle multiple sort orders?

Andrew Gierth <andrew@tao11.riddles.org.uk> 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.
/messages/by-id/5702.1480896563@sss.pgh.pa.us
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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Andrew Gierth
andrew@tao11.riddles.org.uk
In reply to: Tom Lane (#2)
Re: Teaching query_planner to handle multiple sort orders?

"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

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?

Tom> It's been on my to-do list for years, see e.g.
Tom> /messages/by-id/5702.1480896563@sss.pgh.pa.us

Tom> The idea wouldn't have been very helpful before the upper planner
Tom> got path-ified, but now the only stumbling block is a shortage of
Tom> round tuits.

I'll take a shot at it, then.

--
Andrew (irc:RhodiumToad)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers