On Fri, Sep 19, 2014 at 4:30 PM, Andres Freund <and...@anarazel.de> wrote: > On September 19, 2014 10:16:35 PM CEST, Simon Riggs <si...@2ndquadrant.com> > wrote: >>On 19 September 2014 13:04, Robert Haas <robertmh...@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 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
