From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench - allow to create partitioned tables |
Date: | 2019-09-26 21:06:06 |
Message-ID: | 20190926210606.GA3234@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Sep-26, Fabien COELHO wrote:
>
> Hello Alvaro,
>
> > pgbench's main() is overly long already, and the new code being added
> > seems to pollute it even more. Can we split it out into a static
> > function that gets placed, say, just below disconnect_all() or maybe
> > after runInitSteps?
>
> I agree that refactoring is a good idea, but I do not think it belongs to
> this patch. The file is pretty long too, probably some functions could be
> moved to distinct files (eg expression evaluation, variable management,
> ...).
I'm not suggesting to refactor anything as part of this patch -- just
that instead of adding that new code to main(), you create a new
function for it.
> > (Also, we seem to be afraid of function prototypes. Why not move the
> > append_fillfactor() to *below* the functions that use it?)
>
> Because we avoid one more line for the function prototype? I try to put
> functions in def/use order if possible, especially for small functions like
> this one.
I can see that ... I used to do that too. But nowadays I think it's
less messy to put important stuff first, secondary uninteresting stuff
later. So I suggest to move that new function so that it appears below
the code that uses it. Not a big deal anyhow.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Lambert | 2019-09-26 21:13:42 | Re: FETCH FIRST clause PERCENT option |
Previous Message | David Steele | 2019-09-26 21:02:51 | Re: Standby accepts recovery_target_timeline setting? |