Re: Fixing Grittner's planner issues

On Thu, Feb 19, 2009 at 4:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)enterprisedb(dot)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.

Hmm, for some reason I thought hash join would be the harder case
(since the logic to de-dupe the hash table would be all new). In the
merge-join and nest-join cases, isn't this pretty much what JOIN_SEMI
already does?

...Robert