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 | 20150123153934.GM1663@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] (Dilip kumar <dilip.kumar@huawei.com>) |
Ответы |
Re: TODO : Allow parallel cores to be used by vacuumdb [
WIP ]
Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
Список | pgsql-hackers |
Dilip kumar wrote: > Changes: > 1. In current patch vacuum_one_database (for table list), have the table loop outside and analyze_stage loop inside, soit will finish > All three stage for one table first and then pick the next table. But vacuum_one_database_parallel will do the stage loopoutside and will call run_parallel_vacuum, > Which will have table loop, so for one stage all the tables will be vacuumed first, then go to next stage. > So for merging two function both functions behaviors should be identical, I think if user have given a list of tables inanalyze-in-stages, than doing all the table > Atleast for one stage and then picking next stage will be better solution so I have done it that way. Yeah, I think the stages loop should be outermost, as discussed upthread somewhere -- it's better to have initial stats for all tables as soon as possible, and improve them later, than have some tables/dbs with no stats for a longer period while full stats are computed for some specific tables/database. 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.) > 2. in select_loop > For WIN32 TranslateSocketError function I replaced with > if (WSAGetLastError() == WSAEINTR) > errno == EINTR; > > otherwise I have to expose TranslateSocketError function from socket and include extra header. Grumble. Don't like this bit, but moving TranslateSocketError to src/common is outside the scope of this patch, so okay. (pg_dump's parallel stuff has the same issue anyway.) In case you're up for doing some more work later on, there are two ideas here: move the backend's TranslateSocketError to src/common, and try to merge pg_dump's select_loop function with the one in this new code. But that's for another patch anyway (and this new function needs a little battle-testing, of course.) > I have tested in windows also its working fine. Great, thanks. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: