Skip site navigation (1) Skip section navigation (2)

Re: FSM search modes

From: decibel <decibel(at)decibel(dot)org>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Itagaki Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM search modes
Date: 2009-10-01 15:24:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sep 30, 2009, at 5:13 PM, Kevin Grittner wrote:
> decibel <decibel(at)decibel(dot)org> wrote:
>> *any* step that improves dealing with table bloat is extremely
>> welcome, as right now you're basically stuck rebuilding the table.
> +1
> Although, possibly more irritating than actually rebuilding it is
> evaluating borderline bloat situations to determine if they will "work
> themselves out" over time or whether you need to bite the bullet to do
> aggressive maintenance.  Having some way for routine vacuums (or any
> other routine process, currently available or that could be scheduled)
> to "nibble away" at moderate bloat without significant performance or
> usability impact would make life easier for at least *some* DBAs.

Kevin, do you have tools that allow you to clear out the end of a  
table? That part is at least mostly possible from userland (get list  
of ctids from end of table, update those records to move them, rinse,  
repeat) but even if you do all that there's no guarantee that a  
vacuum will get the exclusive lock it needs to truncate the table.

So while something that makes it easier to clean out the end of a  
table would be good, I think the critical need is a way to make  
vacuum more aggressive about obtaining the exclusive lock.
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! Team #1828

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-01 15:35:23
Subject: Re: Use "samehost" by default in pg_hba.conf?
Previous:From: Tom LaneDate: 2009-10-01 15:24:02
Subject: Re: Rejecting weak passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group