Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f15M6-0001KA-P3 for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Mar 2018 07:18:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f15M5-00073m-0t for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Mar 2018 07:18:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f15M4-00073c-LU for pgsql-hackers@lists.postgresql.org; Wed, 28 Mar 2018 07:18:44 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f15M1-0004o0-9s for pgsql-hackers@postgresql.org; Wed, 28 Mar 2018 07:18:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id C638B21C27FC; Wed, 28 Mar 2018 10:18:38 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.200] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 7386B21C27F6; Wed, 28 Mar 2018 10:18:38 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1522221518; bh=7xgti3iesuMhdeQIm2YgX2gDgKopIClIRnS+qYYY1tA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=pRvyvpuwH5nFF/ZlUnmRuX5gh6AsvQGDnDjzTrosJZDVkWzqA9NZBbjoj+ftuAmFA Nj2yglnOKWP+ySrGYm04X43cGyQpUnNHBkR1iEI4vTSWwVKiS+R4JVgiH/eldh0y6T 44LuMI9XasuEARpfCzSmUQyJrWZjRZ7kihtSXQYM= Subject: Re: [HACKERS] Surjective functional indexes To: Simon Riggs Cc: Alvaro Herrera , Stephen Frost , Michael Paquier , Christoph Berg , Thomas Munro , Peter Eisentraut , PostgreSQL Hackers References: <20180322203743.reucnyd7pelkkxom@alvherre.pgsql> <32bb7b6e-b138-9a7c-e74b-7af1365ec4ee@postgrespro.ru> From: Konstantin Knizhnik Message-ID: Date: Wed, 28 Mar 2018 10:18:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 27.03.2018 22:08, Simon Riggs wrote: > On 23 March 2018 at 15:54, Simon Riggs wrote: > >> So please could you make the change? > Committed, but I still think that change would be good. > Thank you. But I still not sure whether replacement of bitmap with List or array of Oids is really good idea. There are two aspects: size and speed. It seems to me that memory overhead is most important. At least you rejected your own idea about using autotune for this parameters because of presence of extra 16 bytes in statistic. But RelationData structure is even more space critical: its size is multiplied by number of relations and backends. Bitmap seems to provide the most compact representation of the projective index list. Concerning speed aspect, certainly iteration through the list of all indexes with checking presence of index in the bitmap is more expensive than just direct iteration through Oid list or array. But since check of bitmap can be done in constant time, both approaches have the same complexity. Also for typical case (< 5 normal indexes for a table and 1-2 functional indexes) difference in performance can not be measured. Also bitmap provides convenient interface for adding new members. To construct array of Oids I need first to determine number of indexes, so I have to perform two loops. So if you and Alvaro insist on this change, then I will definitely do it. But from my point of view, using bitmap here is acceptable solution. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company