Re: TRUE/FALSE vs true/false

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: TRUE/FALSE vs true/false
Дата
Msg-id CA+TgmoazC912BS_W9=6COMOd9jJxtaeER-vcPUY_26hEy9sYMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: TRUE/FALSE vs true/false  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: TRUE/FALSE vs true/false
Список pgsql-hackers
On Thu, Aug 23, 2012 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> On Mon, Aug 20, 2012 at 03:09:08PM -0400, Robert Haas wrote:
>>> I think the thing we need to look at is what percentage of our code
>>> churn is coming from stuff like this, versus what percentage of it is
>>> coming from other factors.  If we change 250,000 lines of code per
>>> release cycle and of that this kind of thing accounts for 5,000 lines
>>> of deltas, then IMHO it's not really material.  If it accounts for
>>> 50,000 lines of deltas out of the same base, that's probably more than
>>> can really be justified by the benefit we're going to get out of it.
>
>> The true/false capitalization patch changes 1.2k lines.
>
> I did a quick look at git diff --stat between recent branches:
>
> $ git diff --shortstat REL9_0_9 REL9_1_5
>  3186 files changed, 314847 insertions(+), 210452 deletions(-)
> $ git diff --shortstat REL9_1_5 REL9_2_BETA4
>  2037 files changed, 290919 insertions(+), 189487 deletions(-)
>
> However, when you look at things a bit closer, these numbers are
> misleading because they include the .po files, which seem to have huge
> inter-branch churn --- well in excess of 100000 lines changed per
> release, at least in git's simpleminded view.  Excluding those, as well
> as src/test/isolation/expected/prepared-transactions.out which added
> 34843 lines all by itself, I get
>         173080 insertions, 70300 deletions for 9.0.9 -> 9.1.5
>         130706 insertions, 55714 deletions for 9.1.5 -> 9.2beta4.
> So it looks like we touch order-of-magnitude of 100K lines per release;
> which still seems astonishingly high, but then this includes docs and
> regression tests not just code.  If I restrict the stat to *.[chyl]
> files it's about half that:
>
> $ git diff --numstat REL9_0_9 REL9_1_5 | grep '\.[chyl]$' | awk '{a += $1; b += $2}
> END{print a,b}'
> 90234 33902
> $ git diff --numstat REL9_1_5 REL9_2_BETA4 | grep '\.[chyl]$' | awk '{a += $1; b += $2}
> END{print a,b}'
> 90200 42218
>
> So a patch of 1K lines would by itself represent about 2% of the typical
> inter-branch delta.  Maybe that's below our threshold of pain, or maybe
> it isn't.  I'd be happier about it if there were a more compelling
> argument for it, but to me it looks like extremely trivial neatnik-ism.

I wouldn't mind a bit if we devoted 2% of our inter-branch deltas to
this sort of thing, but I've got to admit that 2% for one patch seems
a little on the high side to me.  It might not be a bad idea to
establish one formulation or the other as the one to be used in all
new code, though, to avoid making the problem worse.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit kapila
Дата:
Сообщение: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [v9.3] writable foreign tables