Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gPtKD-0008Bd-2g for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Nov 2018 18:03:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gPtKA-0003NW-LF for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Nov 2018 18:03:34 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gPtKA-0003NO-DV for pgsql-hackers@lists.postgresql.org; Thu, 22 Nov 2018 18:03:34 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gPtK2-0004R6-K0 for pgsql-hackers@lists.postgresql.org; Thu, 22 Nov 2018 18:03:33 +0000 Received: by mail-wr1-x42f.google.com with SMTP id z5so5771308wrt.11 for ; Thu, 22 Nov 2018 10:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zFKiEu5e92s0j7Hg5XZH+jgtmq9JftzlNwV2F6WjMV4=; b=cVeDyr32GYelIsLiCX1g9QLer9LtdtxOWcemYxeKPcVvbE5Oq2V6lBRiHcdD6t3CvV XVxr+mMQ3oa77wc9tKOPEZ5fPSgj1s9rDu9t8JoKHT55E0BkCMw/M3uP3zMVU/8bxe2w YKUuEFgkiCSvtxfyMJrUAVOQIqUtjhKDI30ewe7PRq4HqxA2GviAgRqLKpi0UmUdIqIT YqcaguwtLPzrseZpMTJtzcF02cAnesTnhqmLBHD6d/+cjtSfP6aeKWZsrLQHnj1HCtx9 irYcoZEpB4gLJBZLpKHCYAxrzlcxrTrGkG7QWldxHwnf74cYDDhxRDZvOGJvtePl6Das /joQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zFKiEu5e92s0j7Hg5XZH+jgtmq9JftzlNwV2F6WjMV4=; b=RWx4hMnodREomz+2vK+lkFI94fb86sqXYfCIX5tFNU2SOtcKRc1UDj9rSLm2Bd2EoX Wbf6/NWldrVQQT8idp8UUhsStbXizg1rqZTElUKua2VksimTieoQttRAwgqQvarSYrj4 hZbrKOfqNV7K1yOFXhhUXmxmx7jGb8JBiQfmHQ1vvZ2NR3Uci+zrxmF9P6fAVxMQUFIv tKVKfChU16jamLm0eMmHhJK4goeKleFu+OWchJTU4nvEmHRRnUUTXXADfYMf1cBy4Ev4 eeYD8BnJGJYBV3+gsIATNJ1P+csCr7ZfRvPL8MTefvvWSnTnP68E4FNp9VNmoGykjb5u UVhw== X-Gm-Message-State: AA+aEWZavFsG3S179O0fXcB5sNwczh4BdoQPHnlN/A+gPz96CXyuEKIg sAAdaYL30MEspYR2dOmfxAM3q1fu5SbNMswmJlSMCOcXNETI1wmb9eznE5QCnhkmWUu4Oh9I5ve SzDfjeMdY+fluazF9bB/ZzTgL+OxbtjcamN9S2H5zXqH/gMxONxdJ8R3D2wEKpcb6pDPOoPjTr0 0nY0UoyJLQPLQ4qcMkcJw= X-Google-Smtp-Source: AFSGD/Vcs4NNkTqKn0mtAusOkbGV4QuP4k2q6KMIMzAip2BK1R4MFweuXTNM+1ocJhWkQ1IlhUgpqA== X-Received: by 2002:adf:bb44:: with SMTP id x4mr11051741wrg.24.1542909804583; Thu, 22 Nov 2018 10:03:24 -0800 (PST) Received: from [10.137.2.21] (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id w16sm7124813wrp.1.2018.11.22.10.03.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 10:03:23 -0800 (PST) Subject: Re: Tid scan improvements To: David Rowley , Edmund Horner Cc: PostgreSQL Hackers References: From: Tomas Vondra Message-ID: <0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com> Date: Thu, 22 Nov 2018 19:03:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/22/18 8:41 AM, David Rowley wrote: > > ... > > 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the > allocation until it reaches the required size. See how > MakeSharedInvalidMessagesArray() does it. Doing it this way ensures > we always have a power of two sized array which is much nicer if we > ever reach the palloc() limit as if the array is sized at the palloc() > limit / 2 + 1, then if we try to double it'll fail. Of course, it's > unlikely to be a problem here, but... the question would be how to > decide on the initial size. > I think it kinda tries to do that in some cases, by doing this: *numAllocRanges *= 2; ... tidRanges = (TidRange *) repalloc(tidRanges, *numAllocRanges * sizeof(TidRange)); The problem here is that what matters is not numAllocRanges being 2^N, but the number of bytes allocated being 2^N. Because that's what ends up in AllocSet, which keeps lists of 2^N chunks. And as TidRange is 12B, so this is guaranteed to waste memory, because no matter what the first factor is, the result will never be 2^N. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services