Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Дата
Msg-id 20150123182445.GO1663@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Список pgsql-hackers
Alvaro Herrera wrote:

> I'm tweaking your v24 a bit more now, thanks -- main change is to make
> vacuum_one_database be called only to run one analyze stage, so it never
> iterates for each stage; callers must iterate calling it multiple times
> in those cases.  (There's only one callsite that needs changing anyway.)

I made some more changes, particularly so that the TAP test pass (we
were missing the semicolon when a table name was not specified to
prepare_vacuum_command).  I reordered the code in a more sensible
manner, remove the vacuum_database_stage layer (which was pretty
useless), and changed the analyze-in-stages mode: if we pass a valid
stage number, run that stage, if not, then we're not in analyze-in-stage
mode.  So I got rid of the boolean flag altogether.  I also moved the
per-stage commands and messages back into a struct inside a function,
since there's no need to have them be file-level variables anymore.

-j1 is now the same as not specifying anything, and vacuum_one_database
uses more common code in the parallel and not-parallel cases: the
not-parallel case is just the parallel case with a single connection, so
the setup and shutdown is mostly the same in both cases.

I pushed the result.  Please test, particularly on Windows.  If you can
use configure --enable-tap-tests and run them ("make check" in the
src/bin/scripts subdir) that would be good too .. not sure whether
that's expected to work on Windows.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: pg_upgrade and rsync