Re: Fixing Grittner's planner issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: Fixing Grittner's planner issues
Date: 2009-02-19 21:53:34
Message-ID: 26522.1235080414@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-02-19 22:25:15 Re: Fixing Grittner's planner issues
Previous Message Greg Stark 2009-02-19 21:46:47 Re: Fixing Grittner's planner issues