Re: Turning off HOT/Cleanup sometimes
От | Andres Freund |
---|---|
Тема | Re: Turning off HOT/Cleanup sometimes |
Дата | |
Msg-id | 20140919214823.GE13527@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Turning off HOT/Cleanup sometimes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2014-09-19 16:35:19 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On September 19, 2014 10:16:35 PM CEST, Simon Riggs <simon@2ndquadrant.com> wrote: > >> 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. > > Yeah. But it's also the case that we know a good deal more about the > access patterns for system-driven catalog updates than we do about user > queries. ISTM we could probably suppress HOT pruning during catalog > *scans* and instead try to do it when a system-driven heap_update > occurs. > > Having said that, this could reasonably be considered outside the scope > of a patch that's trying to improve the behavior for user queries. > But if the patch author doesn't want to expand the scope like that, > ISTM he ought to ensure that the behavior *doesn't* change for system > accesses, rather than trying to convince us that disabling HOT for > system updates is a good idea. I think it'd have to change for anything not done via the executor. There definitely is user defined code out there doing manual heap_* stuff. I know because i've written some. And I know I'm not the only one. If such paths suddenly stop doing HOT cleanup we'll cause a noticeable amount of pain. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: