From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring pgbench.c |
Date: | 2015-06-29 00:39:13 |
Message-ID: | CAMkU=1wdLetdAcrcrfjn7g_=-5SAzuhGhte9pUA42NeZZcT3Bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii <ishii(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-06-29 01:00:19 | Re: drop/truncate table sucks for large values of shared buffers |
Previous Message | Amit Kapila | 2015-06-29 00:11:30 | Re: drop/truncate table sucks for large values of shared buffers |