Re: Nested loop cost looks too high on 19c

Yes Jonathan, as I had just replied couple of minutes ago it's a 24/7 data load table and stats gather happens manually throughout the scheduled job. But the test system is the one which has been restored from production only. But I doubt that stats gather job is really running there as because data load is not happening in that system 24/7 as it's in production. And so ideally statistics should not change/differ untill someone has manually gathered and 19c algo took effect on the num_distinct value. And so I am thinking, how safe is it to just update the num_distinct at the global level for that column to the same value as that of 11.2 system? Or will it be overridden when next partition gather happens.

On Wed, 1 Jun 2022, 12:39 pm Jonathan Lewis, <jlewisoracle_at_gmail.com> wrote:

>
> Sorry,
> I forget you'd already said granularity=>'PARTITION'
> Does that mean you have a procedure that populates a partition then
> gathers stats (with a trickle of change thereafter)?
>
> Regards
> Jonathan Lewis
>
>
> On Tue, 31 May 2022 at 23:47, Jonathan Lewis <jlewisoracle_at_gmail.com>
> wrote:
>
>>
>> One other thing to check on gathering stats - what was the setting for
>> the granularity paramter?
>>
>> Regards
>> Jonathan Lewis
>>
>>
>>

--
http://www.freelists.org/webpage/oracle-l