On Wed, Oct 13, 2010 at 10:37 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas <robertmhaas(at)gmail(dot)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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-10-14 12:19:07|
|Subject: Re: Issues with Quorum Commit|
|Previous:||From: Dmitriy Igrishin||Date: 2010-10-14 12:14:04|
|Subject: Re: querying the version of libpq|
pgsql-rrreviewers by date
|Next:||From: Greg Smith||Date: 2010-11-13 00:08:15|
|Subject: CommitFest 2010-11: Call for Reviewers|
|Previous:||From: Pavel Stehule||Date: 2010-10-14 04:53:57|
|Subject: Re: wip: functions median and percentile|