On 2014-09-19 16:35:19 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On September 19, 2014 10:16:35 PM CEST, Simon Riggs <si...@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 involving temp 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
