On Wed, Oct 13, 2010 at 10:37 PM, Greg Stark <gsst...@mit.edu> wrote: > On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas <robertmh...@gmail.com> wrote: >> Or to put it more bluntly - what is the "problem with planner and hash >> agg" that all of these functions need to solve? And why does it need >> a flag in pg_proc? Why can't't we leave it to the individual >> functions to perform a sort of one is needed? >> > > So I think that's backwards. Why is the function doing data > manipulations like sorts that we usually put in the plan? Is there > some some key meta information that should be flagged in pg_proc and > general functionality the executor should be providing so that this > general class of problems can be solved efficiently? > > Otherwise I fear lots of things we would expect to be efficient such > as calculating the top, median, and last items in the same sort order > would require three separate sorts of the same data. We have a planner > capable of comparing sort orders and estimating the costs of different > plans, we should be using it.
Good point. I think you're right. I'm not sure what the best design for it is, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers