Re: Fixing Grittner's planner issues
От | Tom Lane |
---|---|
Тема | Re: Fixing Grittner's planner issues |
Дата | |
Msg-id | 26522.1235080414@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fixing Grittner's planner issues (Greg Stark <stark@enterprisedb.com>) |
Ответы |
Re: Fixing Grittner's planner issues
|
Список | 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 по дате отправления: