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

From Jeff Janes
Subject Re: Refactoring pgbench.c
Date
Msg-id CAMkU=1wdLetdAcrcrfjn7g_=-5SAzuhGhte9pUA42NeZZcT3Bw@mail.gmail.com
Whole thread Raw
In response to Refactoring pgbench.c  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii <ishii@postgresql.org> wrote:
Main pgbench logic consists of single file pgbench.c which is 4036
lines of code as of today. This is not a small number and I think it
would be nice if it is divided into smaller files because it will make
it easier to maintain, add or change features of pgbench.  I will come
up with an idea how to split pgbench.c later. In the mean time I
attached a call graph of pgbench.c generated by egypt, which we could
get a basic idea how to split and modularize pgbench.c.

I've never found the raw line count of a file to be a problem, at least not at the 4000 line mark.  

If some functions could be moved to existing libraries (like the functions strtoint64 or doConnect or read_line_from_file or the statistical distribution functions) that would be great, but I assume that would have been done already if there was already a logical place to hold them.  I don't think inventing new libraries just to hold these would be an improvement.

If you provided a suggested dissection, maybe I would find it compelling.  But without seeing a concrete proposal I think the process of refactoring is going to impede other improvements more than the result of refactoring it will promote them.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers
Next
From: Amit Kapila
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers