On Fri, Sep 19, 2014 at 4:30 PM, Andres Freund <[email protected]> wrote: > On September 19, 2014 10:16:35 PM CEST, Simon Riggs <[email protected]> > wrote: >>On 19 September 2014 13:04, Robert Haas <[email protected]> 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 involving temp 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 penalize workloads 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
