From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench stats per script & other stuff |
Date: | 2016-03-03 22:26:40 |
Message-ID: | 20160303222640.GA667644@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I looked at 19.d and I think the design has gotten pretty convoluted. I
think we could simplify with the following changes:
struct script_t gets a new member, of type Command **, which is
initially null.
function process_builtin receives the complete script_t (not individual
memebers of it) constructs the Command ** array and puts it in
script_t's new member; return value is the same script_t struct it got
(except it's now augmented with the Command **array).
function process_file constructs a new script_t from the string list,
creates its Command **array just like process_builtin and returns the
constructed struct.
function addScript receives script_t instead of individual members of
it, and does the appropriate thing.
Alternatively, we could have a different struct that's defined to carry
only the Command ** array (not the command string array) and is returned
by both process_builtin and process_file. Perhaps we could also put the
script weight in there. With this arrangement we don't need to typedef
script_t at all and we can just keep it as an anonymous struct as today.
This is what I tried to describe earlier, but obviously I wasn't clear
enough.
Thanks,
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-03 22:40:40 | Re: pgbench stats per script & other stuff |
Previous Message | Petr Jelinek | 2016-03-03 22:21:23 | Re: VS 2015 support in src/tools/msvc |