Re: -HEAD planner issue wrt hash_joins on dbt3 ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: -HEAD planner issue wrt hash_joins on dbt3 ?
Дата
Msg-id 24158.1158523244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: -HEAD planner issue wrt hash_joins on dbt3 ?  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Ответы Re: -HEAD planner issue wrt hash_joins on dbt3 ?  (Matteo Beccati <php@beccati.com>)
Список pgsql-hackers
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> Tom Lane wrote:
>> The big problem there seems to be the drastic misestimation of the
>> number of rows matching the p_name ~~ '%ghost%' condition.  What does
>> pg_stats have for the p_name column?

> http://www.kaltenbrunner.cc/files/pg_stat_p_name.txt

Hmm ... pattern_sel already applies the operator directly to the
most_common_vals, but in this situation those aren't common enough
to help much.  With such an extensive histogram it is awfully tempting
to assume that the histogram members are a representative sample, and
take the selectivity as being the fraction of histogram entries that
match the pattern.  Maybe drop the first and last histogram entries
on the grounds they're probably outliers.  Thoughts?  What would be a
reasonable minimum histogram size to enable using this approach instead
of the guess-on-the-basis-of-the-pattern code?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dan Thomas"
Дата:
Сообщение: Re: [PATCHES] tiny patch to make vacuumdb -a's database order match pg_dumpall
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: -HEAD planner issue wrt hash_joins on dbt3 ?