Re: pgbench stats per script & other stuff

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-15 21:58:50
Message-ID: 20160315215850.GA41105@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Fabien COELHO wrote:

> >If somebody specifies thousands of -f switches, they will waste a few
> >bytes with each, but I'm hardly concerned about a few dozen kilobytes
> >there ...
> Ok, so you prefer a memory leak. I hate it on principle.

I don't "prefer" memory leaks -- I prefer interfaces that make sense.
Speaking of which, I don't think the arrangement in your patch really
does. I know I suggested it, but now that I look again, it turns out I
chose badly and you implemented a bad idea, so can we go back and fix
it, please?

What I now think should really happen is that the current sql_scripts
array, currently under an anonymous struct, should be a typedef, say
ParsedScript, and get a new member for the weight; process_file and
process_builtin return a ParsedScript. The weight and Command ** should
not be part of script_t at all. In fact, with ParsedScript I don't
think we need to give a name to the anon struct used for builtin
scripts. Rename the current to "desc", to mirror what
is actually put in there from the builtin array struct. Make addScript
receive a ParsedScript and weight, fill in the weight into the struct,
and put it to the array after sanity-checking. (I'm OK with keeping
"name" instead of renaming to "desc", if that change becomes too

No need for N_BUILTIN; we can use lengthof(builtin_script) instead.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-15 22:00:13 Re: Parallel Aggregate
Previous Message David Rowley 2016-03-15 21:50:05 Re: Parallel Aggregate