Nikolay Savvinov

@Zoito3221 @kylie__tyler есть, конечно. а вот по твоему описанию "отношений" и не скажешь.

@oradiag @kylie__tyler По твоему между дружбой и отношениями нет никакой разницы ?

начинаем поединок

@Zoito3221 @kylie__tyler вопрос на засыпку: а почему мы тогда не ходим регистрировать дружбу с друзьями, с которыми нам по кайфу и пр. в госорганы и религиозные заведения? и даже обходимся без обрядов, церемоний и камланий, и вроде всем как-то норм?

@kylie__tyler Можно третий вариант: семья создается двумя людьми которым просто по кайфу находиться в окружении друг друга каждый день, без манипуляций, детей и унижений 🙂

@JemHaydonMoore @tylerblack32 @notyourleader New order would open up some exciting possibilities for Mr Putin (or "deals" as his friend Trump would say). He can start charging reasonable fees for not attacking neighboring countries, for example.

@tylerblack32 @notyourleader Not my intention Tyler. I expect others to be able to think for themselves. It’s not hard surely?

How, exactly, did Zelenskyy disrespect America? by pointing out that Russia has violated ceasefires in the past? by pointing out that Russia was the aggressor? Please, someone explain the disrespect.

@JemHaydonMoore @notyourleader @tylerblack32 As a Russian, let me tell you something. The most simplistic interpretation here is the most accurate one. This is a simple shameless land grab. The goal of the land grab is not so much land per se, but crushing the existing rule-based order.

@notyourleader @tylerblack32 Personally I’d expect some sort of reflection on the history of the conflict & of the periods of alliance between countries. There’s a simplistic rhetoric from the mainstream which quite frankly is insulting.

@JLOracle @tmmdv @PerlDBA @MDWidlake @TanelPoder @NenadNoveljic yes, flags are passed as an argument to dbms_stats.stale, but there has been no truncation, and also the value of the flag parameter is 8 which is same for the vast majority of the tables in the database

@oradiag @tmmdv @PerlDBA @MDWidlake @TanelPoder @NenadNoveljic As far as I can tell, apart from checking whether too much table data has changed (i.e. standard "stale" test) the function checks the flags column of mon_mod$ which currently is set only if the table has been truncated.

hi everyone, does anyone know why in Oracle index stats can get labeled as STALE while this does not happen for the corresponding table? @TanelPoder @JLOracle @NenadNoveljic

@JLOracle @tmmdv @PerlDBA @MDWidlake @TanelPoder @NenadNoveljic since we don't have the code of the package, it would be next to impossible to determine what's happening there. there is an SR open and I'm gonna ask Oracle about it, but somehow I doubt they would tell us much.

@JLOracle @tmmdv @PerlDBA @MDWidlake @TanelPoder @NenadNoveljic the index stale flag is an OR of 2 operants, one is the analyze time comparison you mention, the other one is a call to dbms_stats_internal (for tables there is no such call, only a straightforward comparison of modifications with the threshold).

@JLOracle @tmmdv @PerlDBA @MDWidlake @TanelPoder @NenadNoveljic I checked, and found that indexes were analyzed after the table as they were supposed to, so that condition was false. it's the other condition that is true, i.e. the result of dbms_stats_internal.is_stale on that index.

@tmmdv @PerlDBA @MDWidlake @JLOracle @TanelPoder @NenadNoveljic I don't know how to reproduce it in a controlled environment.

@oradiag @PerlDBA @MDWidlake @JLOracle @TanelPoder @NenadNoveljic If it’s reproducible, have you looked at 10053 trace?

@PerlDBA @tmmdv @MDWidlake @JLOracle @TanelPoder @NenadNoveljic I haven't seen any mention of it, but we empirically established that clearing the stale flag by manually updating the stats resolves the problem with the bad plan. it's just that the flag reappears after some some time (for indexes only) so this solution only works short term

@oradiag @tmmdv @MDWidlake @JLOracle @TanelPoder @NenadNoveljic Is there any mention of checking for STALE? Currently in a motel looking at the beach, and not much access or I would provide more detail.

@tmmdv @MDWidlake @PerlDBA @JLOracle @TanelPoder @NenadNoveljic yes there is a mention of dynamic sampling in the note

@oradiag @MDWidlake @PerlDBA @JLOracle @TanelPoder @NenadNoveljic So the plan w/FTS cost 1 has a note about dynamic sampling being used? Otherwise it could be something else impacting cost calculations.

@JLOracle @MDWidlake @PerlDBA @TanelPoder @NenadNoveljic dbms_stats_internal.is_stale(obj#, null, null, inserts+deletes+updates,rowcnt,flags)

@JLOracle @MDWidlake @PerlDBA @TanelPoder @NenadNoveljic # of blocks as per dba_segments seems reasonable so it doesn't seem to be the case here. interestingly, catost.sql shows that while for tables staleness logic is straightforward (a case stmt compares modifications to threshold), for views it's done with an internal function

@MDWidlake @PerlDBA @JLOracle @TanelPoder @NenadNoveljic when I do a manual explain plan, full table scan is correctly assessed to have cost of 6 equivalent single block reads. the cost in the bad plan shows as 1 which explains why it gets chosen over index access.

@MDWidlake @PerlDBA @JLOracle @TanelPoder @NenadNoveljic I think the flag does make a difference here. my understanding is that stale stats make the optimizer go for dynamic sampling which is known to be suffering from some bugs. I don't have any other explanation why the full table scan cost would be so wrong and so inconsistent

@PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic locking stats is the option we are inclining to, but we still need to understand what's happening here because we know there are other tables with similar behavior, and tables are being added from time to time, so it would be more of a workaround and not a solution

@oradiag @JLOracle @MDWidlake @TanelPoder @NenadNoveljic Maybe consider locking stats on that object, and unlocking only to gather stats. Haven't played with this in awhile, but I believe that if stats are locked they cannot be marked stale. Easy enough to test on a test table/indexes.

@PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic in my case I can observe the impact of stale index stats with my own eyes. I'm not making any generalizations about how common such cases are, but in my situation the impact is there, I have very little doubt about it.

@oradiag @JLOracle @MDWidlake @TanelPoder @NenadNoveljic I had once thought STALE stats affected the optimizer. Everything I could find on that topic said 'No, stale stats do not affect the optimizer' Multiple 10053 traces were examined where STALE stats were involved, nothing found STALE affected optimizer.

@ChandlerDBA @PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic no partitioning involved. need to check about incremental stats.

@HemantKChitale @PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic the answer is very simple. when staleness leads to wrong cardinality or cost estimates, like in my case, it needs to be addressed.

@PerlDBA @oradiag @JLOracle @MDWidlake @TanelPoder @NenadNoveljic Good question. How do DBAs (and worse Developers and Managers !) react when they see the data dictionary stating that some statistics are "stale" ? We have to be careful to interpret "staleness". In my experience most "stale" statuses can be ignored. Only some are important.

@PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic the query runs thousands of times per hour in multiple threads so even for a table as small as this a full scan is making a huge difference on a system level

@PerlDBA @JLOracle @MDWidlake @TanelPoder @NenadNoveljic I have a very serious reason to care. With stale index stats, the optimizer seems to use dynamic sampling instead of stats, and there seems to be a bug, so the costing comes out all wrong and it ends up doing a full scan of a 700+ block table instead of a UQ index lookup