Re: Internal operations when the planner makes a hash join.
От
Alvaro Herrera
Тема
Re: Internal operations when the planner makes a hash
join.
Дата
Msg-id
20100223165339.GF3672@alvh.no-ip.org
Ответ на
Список
Дерево обсуждения
Internal operations when the planner makes a hash join. negora <negora@negora.com>
Re: Internal operations when the planner makes a
hash join. "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Internal operations when the planner makes a hash
join. negora <negora@negora.com>
Re: Internal operations when the planner makes a hash
join. Alvaro Herrera <alvherre@commandprompt.com>
Re: Internal operations when the planner makes a hash
join. Scott Carey <scott@richrelevance.com>
Re: Internal operations when the planner makes a hash join. negora <negora@negora.com>
Re: Internal operations when the planner makes a
hash join. "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Internal operations when the planner makes a hash
join. negora <negora@negora.com>
Re: Internal operations when the planner makes a
hash join. "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Internal operations when the planner makes a hash join. "Igor Neyman" <ineyman@perceptron.com>
negora wrote: > According to how I understood the process, the engine would get the > name from the student with ID 1 and would look for the name of the > father with ID 1 in the hashed table. It'd do exactly the same with the > student #2 and father #2. But my big doubt is about the 3rd one > (Anthony). Would the engine "know" that it already had retrieved the > father's name for the student 1 and would avoid searching for it into > the hashed table (using some kind of internal mechanism which allows to > "re-utilize" the name)? Or would it search into the hashed table again?
The hash table is searched again. But that's fast, because it's a hash table. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-performance по дате отправления