Re: [HACKERS] Teaching query_planner to handle multiple sort orders?

[Andrew Gierth]

> "Tom" == Tom Lane  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> https://postgr.es/m/5702.1480896...@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

Re: [HACKERS] Teaching query_planner to handle multiple sort orders?

[Tom Lane]

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.
https://postgr.es/m/5702.1480896...@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

[HACKERS] Teaching query_planner to handle multiple sort orders?

[Andrew Gierth]

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