Re: How reliable are the stats collector stats?
От | Jan Wieck |
---|---|
Тема | Re: How reliable are the stats collector stats? |
Дата | |
Msg-id | 405C6D1F.7050604@Yahoo.com обсуждение исходный текст |
Ответ на | Re: How reliable are the stats collector stats? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom Lane wrote: > Eric Ridge <ebr@tcdi.com> writes: >> Could pg_stats_user_indexes be lying? > > Jan probably knows this stuff better than I, but my guess is that if the > counter type you are looking at is incrementing at all, then it's not > too far off. I certainly can't think of a failure mechanism that would > cause some indexes to be shown with zero hits when other indexes do > get hits. As described before in various threads, the messages from the backend to the stats collector are unreliable INET UDP on purpose, so that a clogged collector never slows down a backend. If that happens, usually an entire bunch of not necessarily related counter increments on a per transaction base would get lost. > >> I realize the real question is "why aren't these indexes being used", > > Up to a point. If it's a unique index then you may want the > uniqueness-check functionality even if the index is never used for > searches. (I think that pg_stats only counts search probes, not > accesses made in connection with insertions, but I'm too tired to > go double-check this.) That is right. Only scans are counted for. A not scanned non-unique index is obsolete or indicates a planner/casting problem. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: