Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmYf3-008bHn-Mr for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Mar 2024 12:33:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rmYf2-00Dqk2-87 for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Mar 2024 12:33:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmYf1-00Dqju-RG for pgsql-hackers@lists.postgresql.org; Tue, 19 Mar 2024 12:33:44 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmYex-005MWf-Ho for pgsql-hackers@postgresql.org; Tue, 19 Mar 2024 12:33:43 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4TzWNc0csBz49Pys; Tue, 19 Mar 2024 14:33:36 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1710851616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gZW4vBUBaJhWT/hQpzuACFBXXF6sr5e7swcl7RKC1Pw=; b=VOC+rZ2InjbJZ5vrSSbSSbA7bQMw217JiQhaSqOZIya/NVChcxMBTLRAlhlOXZz8bkBJdO uM6bDW9KOVlD3HbldyPXUIEG2sSYHofvCI4lj+KhZWnN7zGIy7+xyVKnMZzOdLlQ75Ovnw oDcRk7z4pYkNZ5qYXa7tVDMeTXKGL6H91VGKGea3MsNkxPDrRZmecOzLoyNGIYdZaFogKy ys7LasPQAYOXMgLhlqajqwkP9sVRQvBr+740JETH0BOiJgUXRZv2oUmWP3cFWl8x1lYH9I w5bLmSVu1bAqj1eOYVgjPfCz2eT29pdFMSlQAZOUr14FQ3pKiCPwVfsw+L1vnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1710851616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gZW4vBUBaJhWT/hQpzuACFBXXF6sr5e7swcl7RKC1Pw=; b=lKTGFCf6qS7Uxccn3sQ0c9KTITmi3ivASZIbn5or32k+a16AGDZ84Dl7Ui06mA9KMt6JYb TVLfLN6VpWq81AMQIYr/+ZZxc0b3kYn1XiTqgjzmusoTsR2KL7ILGp534HDM4XHkJysnFT r+Ry0UvZKOAhlLxx6dD6CsbSi+2c+zjaPIC3zoVYQdHTeg28h+oASFvL2lrcs1Hj+R6QWj i7aK04L1WULLMo53ls+XiXAJeNm1lZHCbN1z5pl34i1y6PzCthXDaKrFaaDmPWLoZP2DS3 MpilwerSoqLfaqmy1ihcix94mouCg68SOLmyW8bHOA5suSqthh83FezT7HrRmg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1710851616; a=rsa-sha256; cv=none; b=Sxk2LOwBrJBHlK2+7ABiKdCoyOU0Nx8PN3FwJejAaXHPArFJHqkafqUm/rihwi6+puwevu yI262KZjmBD8q469oVsD2eKzL0t417rv80LLuxBPKCMaQE4X5GLgUxnBXxEyc/h7KtFmZI dRBvc6Q8/uEgsbkvhazuV62cGo5YWrpXOzqVIl+/RqSllbBWOIDv2v0lnT6MgvZS2pLLFT iiy+FaDexefrb+BXtutKqREcAtcQ91CKqGLyuHKejZBLEVm+e9MBHuMeQvtTZbxGs+yGYs b2guwHpyfvg1W766Cf+4LHme4g4M5C/yT8f0PCaMU1MWu1TwlXT6yRtFJZJvaQ== Message-ID: <5a172d1e-d69c-409a-b1fa-6521214c81c2@iki.fi> Date: Tue, 19 Mar 2024 14:33:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BitmapHeapScan streaming read user and prelim refactoring Content-Language: en-US To: Melanie Plageman Cc: Andres Freund , Pg Hackers , Thomas Munro , Nazir Bilal Yavuz References: <20240214194228.jf4o7luxtyra5ggv@awork3.anarazel.de> <7c2017c3-f12e-4c43-adad-c5ae0f93cd5d@iki.fi> <20240318151947.uu2il7iegi2gkmol@liskov> From: Heikki Linnakangas In-Reply-To: <20240318151947.uu2il7iegi2gkmol@liskov> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 18/03/2024 17:19, Melanie Plageman wrote: > I've attached v7 rebased over this commit. Thanks! > v7-0001-BitmapHeapScan-begin-scan-after-bitmap-creation.patch If we delayed table_beginscan_bm() call further, after starting the TBM iterator, we could skip it altogether when the iterator is empty. That's a further improvement, doesn't need to be part of this patch set. Just caught my eye while reading this. > v7-0003-Push-BitmapHeapScan-skip-fetch-optimization-into-.patch I suggest to avoid the double negative with SO_CAN_SKIP_FETCH, and call the flag e.g. SO_NEED_TUPLE. As yet another preliminary patch before the streaming read API, it would be nice to move the prefetching code to heapam.c too. What's the point of having separate table_scan_bitmap_next_block() and table_scan_bitmap_next_tuple() functions anymore? The AM owns the TBM iterator now. The executor node updates the lossy/exact page counts, but that's the only per-page thing it does now. > /* > * If this is the first scan of the underlying table, create the table > * scan descriptor and begin the scan. > */ > if (!scan) > { > uint32 extra_flags = 0; > > /* > * We can potentially skip fetching heap pages if we do not need > * any columns of the table, either for checking non-indexable > * quals or for returning data. This test is a bit simplistic, as > * it checks the stronger condition that there's no qual or return > * tlist at all. But in most cases it's probably not worth working > * harder than that. > */ > if (node->ss.ps.plan->qual == NIL && node->ss.ps.plan->targetlist == NIL) > extra_flags |= SO_CAN_SKIP_FETCH; > > scan = node->ss.ss_currentScanDesc = table_beginscan_bm( > node->ss.ss_currentRelation, > node->ss.ps.state->es_snapshot, > 0, > NULL, > extra_flags); > } > > scan->tbmiterator = tbmiterator; > scan->shared_tbmiterator = shared_tbmiterator; How about passing the iterator as an argument to table_beginscan_bm()? You'd then need some other function to change the iterator on rescan, though. Not sure what exactly to do here, but feels that this part of the API is not fully thought-out. Needs comments at least, to explain who sets tbmiterator / shared_tbmiterator and when. For comparison, for a TID scan there's a separate scan_set_tidrange() table AM function. Maybe follow that example and introduce scan_set_tbm_iterator(). It's bit awkward to have separate tbmiterator and shared_tbmiterator fields. Could regular and shared iterators be merged, or wrapped under a common interface? -- Heikki Linnakangas Neon (https://neon.tech)