Re: Refactoring pgbench.c - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Refactoring pgbench.c
Date
Msg-id 20150629.015612.47254966807031208.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Refactoring pgbench.c  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Refactoring pgbench.c  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
>> I do not think that this large file is a so big a problem (good
>> editors help navigation in the code), and I'm not sure that splitting
>> it would achieve much: there are not that many functions, some of
>> them are maybe long (main, threadRun, doCustom) but mostly for good
>> reasons.
> 
> My thoughts, exactly. I don't think just splitting the file into
> multiple pieces will achieve anything - the problem is that we've
> extended the original pgbench code in rather hackish way, without any
> major design changes, so IMHO what should be done is refactoring ...

This is kind of surprising to me that two people are against
refactoring proposal (I understand that Fabien has pending patches for
pgbench and that could be a motivation for this though).

Splitting single large file into smaller files in which functions
contain strong relation will be itself a benefit since there will be
more chance for people to be needed to look into smaller places than
before. This is just a basic idea of modular programming and will be a
long term benefit of PostgreSQL project, which was my thought.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers
Next
From: Tomas Vondra
Date:
Subject: Re: Refactoring pgbench.c