Re: Patch - Debug builds without optimization - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Patch - Debug builds without optimization
Date
Msg-id 4E001C2F.6020500@2ndQuadrant.com
Whole thread Raw
In response to Re: Patch - Debug builds without optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 06/20/2011 01:34 PM, Tom Lane wrote:
> I was trying to illustrate how to have minimal turnaround time
> when testing a small code change.  Rebuilding from scratch is slow
> enough that you lose focus while waiting.  (Or I do, anyway.)
>    

I just keep upgrading to the fastest CPU I can possibly justify to avoid 
losing focus; it goes fast with 8 cores.  I was trying to demonstrate 
that peg makes this very high level now, and I was more jousting at the 
idea that everyone should bother to write their own individual reinstall 
script.

The peg code makes it easy to assimilate whatever other neat 
optimization ideas one might come across.  I just pushed an update out 
that absorbed this one, so now if you do:

stop
peg rebuild

It uses the install-bin trick you suggested.  It even does a couple of 
sanity checks so that it will probably fall back to a regular build if 
it doesn't look like you have a good install and binary tree already.  
Maybe I'll make a "reinstall" alias that does this combination next.

I don't expect to improve your workflow.  But people who haven't already 
invested a good chunk of work in automating things already will probably 
take some time to catch up with where peg puts them on day one.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Fwd: Keywords in pg_hba.conf should be field-specific
Next
From: Brendan Jurd
Date:
Subject: Re: Fwd: Keywords in pg_hba.conf should be field-specific