On Fri, Mar 21, 2014 at 12:48 AM, Dilip kumar dilip.ku...@huawei.com 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
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,
On Monday, June 23, 2014, Dilip kumar dilip.ku...@huawei.com 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
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
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 overall
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 size this would
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar dilip.ku...@huawei.com 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
On Thu, Nov 7, 2013 at 8:42 PM, Dilip kumar dilip.ku...@huawei.com 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
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
the
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 code
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-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
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
101 - 113 of 113 matches
Mail list logo
