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
