Re: [previously on HACKERS] "Compacting" a relation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [previously on HACKERS] "Compacting" a relation
Date: 2007-02-19 21:36:51
Message-ID: 200702192136.l1JLapG20018@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Simon Riggs wrote:
> On Mon, 2007-02-05 at 11:55 +0000, Simon Riggs wrote:
> > On Sat, 2007-02-03 at 22:11 -0500, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > > > vacuumlazy.c contains a hint "Consider compacting this relation" but AFAICT,
> > > > > there is no indication anywhere how "compacting" is supposed to be achieved.
> > > > > I guess this means VACUUM FULL or CLUSTER, but I don't think the hint can be
> > > > > processed effectively by a user.
> > > >
> > > > So change it ...
> > >
> > > New message is:
> > >
> > > errhint("Consider using VACUUM FULL on this relation or increasing the configuration parameter \"max_fsm_pages\".")));
> > >
> >
> > The change of wording may be appropriate, but it is triggered when
> >
> > if (vacrelstats->tot_free_pages > MaxFSMPages)
> >
> > So if you VACUUM a 15+GB table and it has only 1% freespace then it will
> > still generate this message. Hopefully you'd agree that the message
> > would be inappropriate in that case.
> >
> > It's also inappropriate because this message is generated *prior* to
> > doing lazy_truncate_heap(), which could easily remove lots of empty
> > pages anyhow. That might reduce it to less than MaxFSMPages anyhow, so
> > it can currently be triggered in wholly inappropriate situations.
> >
> > So I suggest that we move this wording after lazy_truncate_heap() in
> > lazy_vacuum_rel() *and* we alter the hint so that it only suggests
> > VACUUM FULL if the table has 20% fragmentation, whatever its size.
> >
> > Happy to drop a patch for this, if people agree.
>
> Enclose 2 versions:
> v1 - move test and WARNING
> v2 - move test and WARNING, plus adjust hint according to relation size
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-02-19 22:06:28 Re: libpq docs about PQfreemem
Previous Message Bruce Momjian 2007-02-19 21:08:16 Re: Proposed adjustments in MaxTupleSize andtoastthresholds

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2007-02-19 22:29:40 Re: [HACKERS] Deadlock with pg_dump?
Previous Message Bruce Momjian 2007-02-19 21:25:36 Re: BUG #2969: Inaccuracies in Solaris FAQ