Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> It's been clear for quite awhile that a stats target of 10 is often
>> too low, but no one has done the legwork to establish what a more
>> reasonable tradeoff point would be.
> Any ideas on what measurements w
t: Re: [BUGS] Planner problems in 8.2.4 and 8.2.5 (was: Possible planner
bug/regression introduced in 8.2.5)
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Can we switch the default_statistics_target to a default of 100? Is
> there any reason not to do so at this point?
Oth
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It's been clear for quite awhile that a stats target of 10 is often
> too low, but no one has done the legwork to establish what a more
> reasonable tradeoff point would be.
Any ideas on what measurements would be interesting for this?
--
Gregory St
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Can we switch the default_statistics_target to a default of 100? Is
> there any reason not to do so at this point?
Other than a 10x increase in the cost of ANALYZE, and in the cost of
histogram-based operations in the planner?
It's been clear f
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied:
> If there are 100 or more histogram entries it'll do the estimation by
> counting how many of the histogram entries match the pattern, rather
> than using the prefix-range-based estimator (which is pretty much
> all-fantasy an
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I tried the patch you sent, with no change. However, I then changed the
> default_statistics_target to 100, reanalyzed, and it came back with the
> "good" plan. Trying this on the original larger query (which pulls from
> tables with millions o
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Is there a reason you rounded off most of the costs? It looks like the
> estimated costs of the two join types are nearly equal, and so it's pure
> chance which one gets chosen.
No real reason, it's just a post-processing script used to make
I wrote:
>> This might be a bug in the LIKE estimator (if so, it's in 8.2.3 as
>> well). I don't have time to look closer right now, but can you show us
>> the pg_stats row for orders_smaller.order_number?
> Oh, never mind that ... on inspection, the NOT LIKE selectivity
> estimator is obviously
I wrote:
> This might be a bug in the LIKE estimator (if so, it's in 8.2.3 as
> well). I don't have time to look closer right now, but can you show us
> the pg_stats row for orders_smaller.order_number?
Oh, never mind that ... on inspection, the NOT LIKE selectivity
estimator is obviously broken:
Greg Sabino Mullane <[EMAIL PROTECTED]> writes:
> I don't have a full test case yet, but I did finally manage to get an
> explain analyze to finish in a sane amount of time on 8.2.5. Attached
> are two cleaned up explain analyze results, using the exact same data
> directory but different executabl
I don't have a full test case yet, but I did finally manage to get an
explain analyze to finish in a sane amount of time on 8.2.5. Attached
are two cleaned up explain analyze results, using the exact same data
directory but different executables: one is 8.2.3 and returns as
expected, the other is 8
11 matches
Mail list logo
