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 1shJPI-00GBzx-57 for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Aug 2024 01:48:04 +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 1shJPE-007wr1-3X for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Aug 2024 01:48:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1shJPD-007wqq-6S for pgsql-bugs@lists.postgresql.org; Fri, 23 Aug 2024 01:48:00 +0000 Received: from m16.mail.163.com ([117.135.210.3]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1shJP7-000zKr-3L for pgsql-bugs@lists.postgresql.org; Fri, 23 Aug 2024 01:47:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=FNGELBESupY00YgPvKazLbC0/lq4gB16+gsquYygCGs=; b=n2RXoPXHQwYbL2JguwxEGoz99b9EEjjF2+HwK2tT4vCkl3WoAQRohXwmVy9BY2 C/kSGOQ54sbwRJrgh3iThWgZncHFkPieQ76wGF14/+fGBoszo079yNxreCw3+ynl 5FRujUolpT4PUFwi4AzlqeVV6DXw3QpbM0DgocHq2S5U4= Received: from lovely-coding (unknown [101.227.46.166]) by gzga-smtp-mta-g2-4 (Coremail) with SMTP id _____wDnD6RB6sdmDBWBCw--.29155S3; Fri, 23 Aug 2024 09:47:46 +0800 (CST) From: Andy Fan To: David Rowley Cc: Tom Lane , Maxim Boguk , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18588: Cannot force/let database use parallel execution in simple case. In-Reply-To: (David Rowley's message of "Fri, 23 Aug 2024 11:11:40 +1200") References: <18588-204730f9394441a8@postgresql.org> <2059550.1724353316@sss.pgh.pa.us> <2073208.1724359323@sss.pgh.pa.us> <2088498.1724367160@sss.pgh.pa.us> Date: Fri, 23 Aug 2024 09:47:45 +0800 Message-ID: <87h6bcrovy.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wDnD6RB6sdmDBWBCw--.29155S3 X-Coremail-Antispam: 1Uf129KBjvdXoWrtFW7tF47XryrZryUAF13urg_yoW3Gwc_uw 4xAFWqkw15tF9xW3ZFy3W5XrW0v342kF10gw4UKFsrX343CwsxJrn5Gr1S9F15KFWYgFnx Gas8Jw4Ykry3WjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUUr-P5UUUUU== X-Originating-IP: [101.227.46.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBhQJEU2WXwlNLNgAAsO List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > .. I think Maxim might need to try tweaking effective_cache_size. .. I'm right now doing some troubleshooting for Bitmap Index Scan vs Index Scan and effective_cache_size caught my attention. I want to take this chance to confirm my understanding about this parameter. 1. By design, effective_cache_size should not less than shared_buffer since file-system cache should be considered as well. 2. Mackert and Lohman's algorithm in index_pages_fetched looks doesn't consider the number of concurrency? so if we have N sessions to access N different small relations, but sum_of_n_relations is larger than effective_cache_size, would the index_pages_fetched figure out a much smaller value than the fact? -- Best Regards Andy Fan