Re: pgbench - allow to create partitioned tables

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Asif Rehman <asifr.rehman@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-26T21:06:06Z
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



Commits

  1. pgbench: add --partitions and --partition-method options.