|From:||Simon Riggs <simon(at)2ndquadrant(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] autovacuum: use case for indenpedent TOAST table autovac settings|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, 2008-08-13 at 21:30 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> >> It seems like we'll want to do it somehow. Perhaps the cleanest way is
> >> to incorporate toast-table settings in the reloptions of the parent
> >> table. Otherwise dump/reload is gonna be a mess.
> > My question is whether there is interest in actually having support for
> > this, or should we just inherit the settings from the main table. My
> > gut feeling is that this may be needed in some cases, but perhaps I'm
> > overengineering the thing.
> It seems reasonable to inherit the parent's settings by default, in any
> case. So you could do that now and then extend the feature later if
> there's real demand.
Yeh, I can't really see a reason why you'd want to treat toast tables
differently with regard to autovacuuming. It's one more setting to get
wrong, so no thanks.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
|Next Message||Jan Urbański||2008-08-14 09:53:25||Re: gsoc, oprrest function for text search take 2|
|Previous Message||Heikki Linnakangas||2008-08-14 09:42:10||Re: gsoc, oprrest function for text search take 2|
|Next Message||Gregory Stark||2008-08-14 10:12:00||Re: Incorrect estimates on correlated filters|
|Previous Message||Craig Ringer||2008-08-14 01:48:03||Re: Incorrect estimates on correlated filters|