On Fri, Jun 27, 2014 at 4:10 AM, Dilip kumar wrote:
...
>
> Updated patch is attached in the mail..
Thanks Dilip.
I get a compiler warning when building on Windows. When I started
looking into that, I see that two files have too much code duplication
between them:
src/bin/scripts/vac_parallel.
On Thu, Jun 26, 2014 at 2:35 AM, Dilip kumar wrote:
>
> Thank you for giving your time, Please review the updated patch attached in
> the mail.
>
>
>
> 1. Rebased the patch
>
> 2. Implemented parallel execution for new option --analyze-in-stages
Hi Dilip,
Thanks for rebasing.
I have
Hi,
I got following FAILED when I patched v3 to HEAD.
$ patch -d. -p1 < ../patch/vacuumdb_parallel_v3.patch
patching file doc/src/sgml/ref/vacuumdb.sgml
Hunk #1 succeeded at 224 (offset 20 lines).
patching file src/bin/scripts/Makefile
Hunk #2 succeeded at 65 with fuzz 2 (offset -1 lines).
patchi
On 24 June 2014 11:02 Jeff Wrote,
>I mean that the other commit, the one conflicting with your patch, is still
>not finished. It probably would not have been committed if we realized the
>problem at the time. That other patch runs analyze in stages at
> different settings of default_statistics
On Monday, June 23, 2014, Dilip kumar wrote:
> On 24 June 2014 03:31, Jeff Wrote,
>
> > > Attached the latest updated patch
> > > 1. Rebased the patch to current GIT head.
> > > 2. Doc is updated.
> > > 3. Supported parallel execution for all db option also.
> >
> > This patch needs to be reb
On 24 June 2014 03:31, Jeff Wrote,
> > Attached the latest updated patch
> > 1. Rebased the patch to current GIT head.
> > 2. Doc is updated.
> > 3. Supported parallel execution for all db option also.
>
> This patch needs to be rebased after the analyze-in-stages patch,
> c92c3d50d7fbe7391b5
On Fri, Mar 21, 2014 at 12:48 AM, Dilip kumar wrote:
> On 16 January 2014 19:53, Euler Taveira Wrote,
>
>> >
>> >> For the case where you have tables of varying size this would lead
>> to a reduced overall processing time as it prevents large (read: long
>> processing time) tables to be processed
Euler Taveira wrote:
> On 08-11-2013 06:20, Dilip kumar wrote:
> > On 08 November 2013 13:38, Jan Lentfer
> >
> >
> >> For this use case, would it make sense to queue work (tables) in order of
> >> their size, starting on the largest one?
> >
> >> For the case where you have tables of varying s
On 08-11-2013 06:20, Dilip kumar wrote:
> On 08 November 2013 13:38, Jan Lentfer
>
>
>> For this use case, would it make sense to queue work (tables) in order of
>> their size, starting on the largest one?
>
>> For the case where you have tables of varying size this would lead to a
>> reduced
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar wrote:
> This patch implementing the following TODO item
>
> Allow parallel cores to be used by vacuumdb
> http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com
Cool. Could you add this patch to the next commit fest for 9.4? It
begins offici
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar wrote:
> This patch implementing the following TODO item
>
> Allow parallel cores to be used by vacuumdb
> http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com
>
>
>
> Like Parallel pg_dump, vacuumdb is provided with the option to run the
>
On 08-11-2013 05:07, Jan Lentfer wrote:
> For the case where you have tables of varying size this would lead to
> a reduced overall processing time as it prevents large (read: long
> processing time) tables to be processed in the last step. While
> processing large tables at first and filling up "p
On 08 November 2013 13:38, Jan Lentfer
> For this use case, would it make sense to queue work (tables) in order of
> their size, starting on the largest one?
> For the case where you have tables of varying size this would lead to a
> reduced overall processing time as it prevents large (read:
On 08 November 2013 03:22, Euler Taveira Wrote
> On 07-11-2013 09:42, Dilip kumar wrote:
>
> Dilip, this is on my TODO for 9.4. I've already had a half-backed patch
> for it. Let's see what I can come up with.
Ok, Let me know if I can contribute to this..
> > Is it required to move the common
Am 07.11.2013 12:42, schrieb Dilip kumar:
> This patch
implementing the following TODO item
>
> Allow parallel cores to be
used by vacuumdb
>
>
http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com [1]
>
> Like Parallel pg_dump, vacuumdb is provided with the option to run
th
On 07-11-2013 09:42, Dilip kumar wrote:
Dilip, this is on my TODO for 9.4. I've already had a half-backed patch
for it. Let's see what I can come up with.
> Is it required to move the common code for parallel operation of pg_dump and
> vacuumdb to one place and reuse it ?
>
I'm not sure about t
101 - 116 of 116 matches
Mail list logo
