Re: Turning off HOT/Cleanup sometimes
От | Robert Haas |
---|---|
Тема | Re: Turning off HOT/Cleanup sometimes |
Дата | |
Msg-id | CA+Tgmoak2n3yXtH5rfSFKpPdYNj-sWnyUwp5UNF5BVV+GhpV6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Turning off HOT/Cleanup sometimes (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Turning off HOT/Cleanup sometimes
|
Список | pgsql-hackers |
On Fri, Sep 19, 2014 at 4:30 PM, Andres Freund <andres@anarazel.de> wrote: > On September 19, 2014 10:16:35 PM CEST, Simon Riggs <simon@2ndquadrant.com> wrote: >>On 19 September 2014 13:04, Robert Haas <robertmhaas@gmail.com> wrote: >> >>> What I'm thinking about is that the smarts to enable pruning is all >>in >>> the executor nodes. So anything that updates the catalog without >>> going through the executor will never be subject to pruning. That >>> includes nearly all catalog-modifying code throughout the backend. >> >>Are you saying this is a problem or a benefit? (and please explain >>why). > > I have no idea what Robert is thinking of, but I'd imagine its horrible for workloads with catalog bloat. Like ones involvingtemp tables. Right, that's what I was going for. > I generally have serious doubts about disabling it generally for read workloads. I imagine it e.g. will significantly penalizeworkloads where its likely that a cleanup lock can't be acquired every time... I share that doubt. But I understand why Simon wants to do something, too, because the current situation is not great either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: