Re: benchmarking the query planner

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: benchmarking the query planner
Дата
Msg-id 11006.1229029042@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: benchmarking the query planner  ("Robert Haas" <robertmhaas@gmail.com>)
Ответы Re: benchmarking the query planner  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Re: benchmarking the query planner  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
>> On the whole I think we have some evidence here to say that upping the
>> default value of default_stats_target to 100 wouldn't be out of line,
>> but 1000 definitely is.  Comments?

> Do you think there's any value in making it scale based on the size of
> the table?

As far as the MCVs go, I think we already have a decent heuristic for
determining the actual length of the array, based on discarding values
that have too small an estimated frequency --- look into
compute_scalar_stats.  I don't see that explicitly considering table
size would improve that.  It might be worth limiting the size of the
histogram, as opposed to the MCV list, for smaller tables.  But that's
not relevant to the speed of eqjoinsel, and AFAIK there aren't any
estimators that are O(N^2) in the histogram length.
(ineq_histogram_selectivity is actually O(log N), so it hardly cares at
all.)

> Otherwise, I am a bit concerned that 10 -> 100 may be too big a jump
> for one release, especially since it may cause the statistics to get
> toasted in some cases, which comes with a significant performance hit.
>  I would raise it to 30 or 50 and plan to consider raising it further
> down the road.  (I realize I just made about a million enemies with
> that suggestion.)

There's something in what you say, but consider that we have pretty
much unanimous agreement that 10 is too small.  I think we should
try to fix the problem, not just gradually ratchet up the value until
people start complaining in the other direction.  (Also, we should have
plenty of opportunity during beta to find out if we went too far.)
        regards, tom lane


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Function with default value not replacing old definition of the function
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)