Re: Refactoring pgbench.c

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tomas(dot)vondra(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Refactoring pgbench.c
Date: 2015-06-28 16:56:12
Message-ID: 20150629.015612.47254966807031208.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-06-28 18:18:13 Re: Refactoring pgbench.c
Previous Message Tom Lane 2015-06-28 16:17:18 Re: drop/truncate table sucks for large values of shared buffers