Re: Fixing Grittner's planner issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing Grittner's planner issues
Date
Msg-id 26522.1235080414@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing Grittner's planner issues  (Greg Stark <stark@enterprisedb.com>)
Responses Re: Fixing Grittner's planner issues  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> It's tempting to have Hash cheat and just peek at the node beneath it
> to see if it's a HashAggregate, in which case it could call a special
> method to request the whole hash. But it would have to know that it's
> just a plain uniquify and not implementing a GROUP BY.

More to the point, it would have to check if it's unique-ifying on the
same columns and with the same operators as the upper hash is using.
If we were going to do something like this, making it a real option to
the Hash node and teaching the planner about that would be *much*
easier, and would also allow saner cost estimation.

I agree that doing something like this on the inner side of a hashjoin
might not be too unreasonable --- it was the mergejoin case that really
seemed ugly when I thought about it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Fixing Grittner's planner issues
Next
From: Robert Haas
Date:
Subject: Re: Fixing Grittner's planner issues