Re: -HEAD planner issue wrt hash_joins on dbt3 ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: -HEAD planner issue wrt hash_joins on dbt3 ?
Date
Msg-id 24158.1158523244@sss.pgh.pa.us
Whole thread Raw
In response to Re: -HEAD planner issue wrt hash_joins on dbt3 ?  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: -HEAD planner issue wrt hash_joins on dbt3 ?  (Matteo Beccati <php@beccati.com>)
List 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 by date:

Previous
From: "Dan Thomas"
Date:
Subject: Re: [PATCHES] tiny patch to make vacuumdb -a's database order match pg_dumpall
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: -HEAD planner issue wrt hash_joins on dbt3 ?