Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
От | Robert Haas |
---|---|
Тема | Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets |
Дата | |
Msg-id | 603c8f070812230622i57150a8ewa41ac8355604a88a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets ("Bryce Cutt" <pandasuit@gmail.com>) |
Ответы |
Re: Proposed Patch to Improve Performance of Multi-Batch
Hash Join for Skewed Data Sets
|
Список | pgsql-hackers |
On Tue, Dec 23, 2008 at 2:21 AM, Bryce Cutt <pandasuit@gmail.com> wrote: > Because there is no nice way in PostgreSQL (that I know of) to derive > a histogram after a join (on an intermediate result) currently > usingMostCommonValues is only enabled on a join when the outer (probe) > side is a table scan (seq scan only actually). See > getMostCommonValues (soon to be called > ExecHashJoinGetMostCommonValues) for the logic that determines this. It's starting to seem to me that the case where this patch provides a benefit is so narrow that I'm not sure it's worth the extra code. Admittedly, when it works, it is pretty dramatic, as in the numbers that I posted previously. I'm OK with the fact that it is restricted to hash joins on a single variable where the probe relation is a sequential scan, because that actually happens pretty frequently, at least in my queries. But, if there's no way to consistently get any benefit out of this when joining more than two tables, then I'm not sure it's worth it. Is it realistic to think that the MCVs of the base relation might still be applicable to the joinrel? It's certainly easy to think of counterexamples, but it might be a good approximation more often than not. ...Robert
В списке pgsql-hackers по дате отправления: