From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olegrok@tarantool.org>
Received: from smtp63.i.mail.ru (smtp63.i.mail.ru [217.69.128.43])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 2E8DF4696C3
 for <tarantool-patches@dev.tarantool.org>;
 Fri,  1 May 2020 20:01:15 +0300 (MSK)
From: Oleg Babin <olegrok@tarantool.org>
References: <cover.1588292014.git.v.shpilevoy@tarantool.org>
 <0bf7b575c617bf49904c4f6fc51a0b9f163e111a.1588292014.git.v.shpilevoy@tarantool.org>
Message-ID: <cce95699-12bb-3934-c07f-7bb655dd770e@tarantool.org>
Date: Fri, 1 May 2020 20:01:10 +0300
MIME-Version: 1.0
In-Reply-To: <0bf7b575c617bf49904c4f6fc51a0b9f163e111a.1588292014.git.v.shpilevoy@tarantool.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH vshard 5/7] router: keep known
 bucket count stat up to date
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tarantool-patches@dev.tarantool.org

Thanks for the patch. LGTM.

On 01/05/2020 03:16, Vladislav Shpilevoy wrote:
> Known bucket count was calculated on demand when router.info() was
> called. Now it is going to be needed for advanced discovery. The
> optimization will be that if known bucket count is equal to total
> bucket count, the discovery enters 'idle' mode, when it works much
> less aggressive, therefore reducing load on the cluster. Which can
> be quite big when bucket count is huge.
> 
> Part of #210