Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAdh8-0008K3-2Q for pgsql-performance@arkaria.postgresql.org; Fri, 03 Nov 2017 15:15:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eAdh6-0007iW-Qo for pgsql-performance@arkaria.postgresql.org; Fri, 03 Nov 2017 15:15:40 +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.84_2) (envelope-from ) id 1eAdfK-0004XZ-OS for pgsql-performance@postgresql.org; Fri, 03 Nov 2017 15:13:50 +0000 Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eAdfG-0000nA-GY for pgsql-performance@postgresql.org; Fri, 03 Nov 2017 15:13:49 +0000 Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id B445D1E0BC2 for ; Fri, 3 Nov 2017 09:13:42 -0600 (MDT) Received: from host214.hostmonster.com ([74.220.215.214]) by cmgw3 with id VTDe1w01E4e7MuJ01TDhh8; Fri, 03 Nov 2017 09:13:42 -0600 X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=E7lA7DdVRVhKYBNJxJVZOg==:117 a=E7lA7DdVRVhKYBNJxJVZOg==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=epTmVMiNAAAA:8 a=XKtS7LnWpgzMYBrR6mgA:9 a=QEXdDO2ut3YA:10 a=FVJFfVuqv3cA:10 a=crwm78qdttAA:10 a=ndEWmUVY6Yapc0oHF_P4:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gusw.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7plti+UXUwOHYPluj8Se6UP/ZWcCfwEWTyi93yVkW+A=; b=UE2Cl68x0r9ouPgce4kB80l1af RmhdqJ6ore1RjL8iMhTDifQlwuSQkYACMy0ueei0qv7tttmpd6lRUVOgmZHb/cB/W0HQcS6I7dNmt f9wVpmsNKlYy0IqZ6fX37LiK7; Received: from [191.7.145.23] (port=60734 helo=[192.168.9.4]) by host214.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eAdf8-00269M-Ib for pgsql-performance@postgresql.org; Fri, 03 Nov 2017 09:13:38 -0600 Subject: Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices To: pgsql-performance@postgresql.org References: <1509611428.3268.5.camel@cybertec.at> <1509701327868-0.post@n3.nabble.com> <9a76f13e-cdb1-1d8d-2178-67e6dcf169bc@gusw.net> <1509720945908-0.post@n3.nabble.com> From: Gunther Message-ID: Date: Fri, 3 Nov 2017 11:13:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509720945908-0.post@n3.nabble.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host214.hostmonster.com X-AntiAbuse: Original Domain - postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gusw.net X-BWhitelist: no X-Source-IP: 191.7.145.23 X-Exim-ID: 1eAdf8-00269M-Ib X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.9.4]) [191.7.145.23]:60734 X-Source-Auth: gunther+pragmaticdata.com X-Email-Count: 6 X-Source-Cap: cHJhZ21hdDE7cHJhZ21hdDE7aG9zdDIxNC5ob3N0bW9uc3Rlci5jb20= X-Local-Domain: yes List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 11/3/2017 10:55, legrand legrand wrote: > To limit NL usage, wouldn't a modified set of Planner Cost Constants > https://www.postgresql.org/docs/current/static/runtime-config-query.html > > > seq_page_cost > random_page_cost > cpu_tuple_cost > cpu_index_tuple_cost > cpu_operator_cost > > be more hash join freindly (as Oracle' optimizer_index_cost_adj )? > I twiddled with some of these and could nudge it toward a Sort Merge instead NL. But it's hit or miss. May be there should be a tool which you can run periodically which will test out the installation to see how IO, CPU, and memory performs. Or, again, these statistics should be collected during normal operation so that nobody needs to guess them or test them in complex procedures. As the system runs, it should sample the seq_page_cost and random_page_cost (noticing that it has a SSD or HDD) and it should see how much disk read is from cache and how much goes out to disk. Why isn't the executor of queries the best person to ask for these cost constants? regards, -Gunther -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance