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