Re: [HACKERS] Highly Variable Planning Times
От
Andres Freund
Тема
Re: [HACKERS] Highly Variable Planning Times
Дата
Msg-id
20170419234840.qubw2fdaeijoc4cu@alap3.anarazel.de
Ответ на
Re: [HACKERS] Highly Variable Planning Times (Michael Malis)
Список
Дерево обсуждения
[HACKERS] Highly Variable Planning Times Michael Malis <michaelmalis2@gmail.com>
Re: [HACKERS] Highly Variable Planning Times Andres Freund <andres@anarazel.de>
Re: [HACKERS] Highly Variable Planning Times Michael Malis <michaelmalis2@gmail.com>
Re: [HACKERS] Highly Variable Planning Times Andres Freund <andres@anarazel.de>
Re: [HACKERS] Highly Variable Planning Times Andres Freund <andres@anarazel.de>
Re: [HACKERS] Highly Variable Planning Times Michael Malis <michaelmalis2@gmail.com>
Re: [HACKERS] Highly Variable Planning Times Andres Freund <andres@anarazel.de>
Re: [HACKERS] Highly Variable Planning Times Michael Malis <michaelmalis2@gmail.com>
Re: [HACKERS] Highly Variable Planning Times Alvaro Herrera <alvherre@2ndquadrant.com>
Re: [HACKERS] Highly Variable Planning Times Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Highly Variable Planning Times Michael Malis <michaelmalis2@gmail.com>
Re: [HACKERS] Highly Variable Planning Times Greg Stark <stark@mit.edu>
Re: [HACKERS] Highly Variable Planning Times Jeff Janes <jeff.janes@gmail.com>
On 2017-04-19 16:43:07 -0700, Michael Malis wrote: > > The profile seems to confirm that this is largely due to cache misses. > > Can you elaborate? Cache misses of what? Why is the planning time so > variable? Postgres uses caches for a lot of metadata of tables, indexes, ... Some actions, like vacuum, DDL, table size changes trigger cache invalidations for other backends so the caches stay coherent. What you're likely seeing is that the cached cases are quick enough, and that the slow plan cycles are when the cache has been invalidated. - Andres
В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата: