Re: benchmarking the query planner - Mailing list pgsql-hackers

From Tom Lane
Subject Re: benchmarking the query planner
Date
Msg-id 11006.1229029042@sss.pgh.pa.us
Whole thread Raw
In response to Re: benchmarking the query planner  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: benchmarking the query planner  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Re: benchmarking the query planner  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Function with default value not replacing old definition of the function
Next
From: Peter Eisentraut
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)