| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Per table autovacuum vacuum cost limit behaviour strange |
| Date: | 2014-10-03 16:06:33 |
| Message-ID: | 20141003160632.GC7043@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost wrote:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > I am rather surprised that nobody has reported this problem before. I
> > am now of the mind that this is clearly a bug that should be fixed all
> > the way back.
>
> I'm coming around to that also, however, should we worry about users who
> set per-table settings and then simply forgot about them? I suppose
> that won't matter too much unless the table is really active, and if it
> is, they've probably already set it to zero.
Right.
For the cases where it's been set and forgotten, perhaps we can have an
item in release notes to tell people to look into tables with the
parameters set in pg_class.reloptions (to any value different from zero)
and to look for performance differences from previous versions when they
are.
I have pushed this now, backpatch all the way back to 9.0.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2014-10-03 16:07:07 | Re: replicating DROP commands across servers |
| Previous Message | Ilya Kosmodemiansky | 2014-10-03 15:56:08 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |