Re: pgbench stats per script & other stuff
От | Alvaro Herrera |
---|---|
Тема | Re: pgbench stats per script & other stuff |
Дата | |
Msg-id | 20160315215850.GA41105@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgbench stats per script & other stuff (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgbench stats per script & other stuff
|
Список | 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 sql_scripts.name 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 invasive.) No need for N_BUILTIN; we can use lengthof(builtin_script) instead. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: