Re: Patch - Debug builds without optimization

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Patch - Debug builds without optimization
Дата
Msg-id 4E001C2F.6020500@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Patch - Debug builds without optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Fwd: Keywords in pg_hba.conf should be field-specific
Следующее
От: Brendan Jurd
Дата:
Сообщение: Re: Fwd: Keywords in pg_hba.conf should be field-specific