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 g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
