Re: -HEAD planner issue wrt hash_joins on dbt3 ?
От | Tom Lane |
---|---|
Тема | Re: -HEAD planner issue wrt hash_joins on dbt3 ? |
Дата | |
Msg-id | 5701.1158003165@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | -HEAD planner issue wrt hash_joins on dbt3 ? (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: -HEAD planner issue wrt hash_joins on dbt3 ?
|
Список | pgsql-hackers |
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: > btw - the "hashjoin is bad" was more or less based on the observation > that nearly all of the cpu is burned in hash-related functions in the > profile (when profiling over a longer period of time those accumulate > even more % of the time than in the short profile I included in the > original report) [ shrug... ] Two out of the three functions you mentioned are not used by hash join, and anyway the other plan probably has a comparable execution density in sort-related functions; does that make it bad? It's possible that the large time for ExecScanHashBucket has something to do with skewed usage of the hash buckets due to an unfortunate data distribution, but that's theorizing far in advance of the data. regards, tom lane
В списке pgsql-hackers по дате отправления: