On Thu, Feb 19, 2009 at 4:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
