Re: Hot Standby tuning for btree_xlog_vacuum() - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Hot Standby tuning for btree_xlog_vacuum()
Date
Msg-id E05A2FDD-8B3B-4288-822C-F1BE58BB463A@decibel.org
Whole thread Raw
In response to Re: Hot Standby tuning for btree_xlog_vacuum()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hot Standby tuning for btree_xlog_vacuum()
List pgsql-hackers
On Apr 29, 2010, at 3:20 PM, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Objections to commit?
>
> This is not the time to be hacking stuff like this.  You haven't even
> demonstrated that there's a significant performance issue here.

I tend to agree that this point of the cycle isn't a good one to be making changes, but your performance statement
confusesme. If a fairly small patch means we can avoid un-necessary reads why shouldn't we avoid them? 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: GUCs that need restart
Next
From: Jim Nasby
Date:
Subject: Re: SELECT * in a CREATE VIEW statement doesn't update column set automatically