From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Dilip kumar <dilip(dot)kumar(at)huawei(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br> |
Subject: | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |
Date: | 2015-01-23 15:39:34 |
Message-ID: | 20150123153934.GM1663@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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, so it will finish
> All three stage for one table first and then pick the next table. But vacuum_one_database_parallel will do the stage loop outside 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 in analyze-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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-01-23 15:57:53 | Re: WITH CHECK and Column-Level Privileges |
Previous Message | Sawada Masahiko | 2015-01-23 15:27:49 | Re: Proposal: knowing detail of config files via SQL |