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

Re: [HACKERS] WAL logging freezing

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] WAL logging freezing
Date: 2006-10-31 19:56:59
Message-ID: 20061031195659.GD12008@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Gregory Stark wrote:
> 
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
> > The added WAL volume should be pretty minimal, because only tuples that have
> > gone untouched for a long time incur extra work.
> 
> That seems like a weak point in the logic. It seems like it would make VACUUM
> which is already an i/o hog even more so. Perhaps something clever can be done
> with vacuum_cost_delay and commit_siblings.
> 
> Something like inserting the delay between WAL logging and syncing the log and
> writing to the heap. So if another transaction commits in the meantime we can
> skip the extra fsync and continue.

Huh, but the log would not be flushed for each operation that the vacuum
logs.  Only when it's going to commit.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2006-10-31 20:45:17
Subject: TODO Item: IN(long list ...)
Previous:From: Gregory StarkDate: 2006-10-31 19:49:27
Subject: Re: [HACKERS] WAL logging freezing

pgsql-patches by date

Next:From: Tom LaneDate: 2006-10-31 20:59:17
Subject: Alternative patches for the btree deletion issue
Previous:From: Gregory StarkDate: 2006-10-31 19:49:27
Subject: Re: [HACKERS] WAL logging freezing

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