Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbE3g-0006NE-T5 for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 17:25:56 +0000 Received: from wsip-72-214-29-243.sd.sd.cox.net ([72.214.29.243] helo=joeconway.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbE3f-00083m-30 for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 17:25:56 +0000 Received: from www.joeconway.com (account jconway [192.168.4.40] verified) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 12473400; Wed, 21 Nov 2012 09:25:52 -0800 Message-ID: <50AD0EA0.7070009@joeconway.com> Date: Wed, 21 Nov 2012 09:25:52 -0800 From: Joe Conway User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Heikki Linnakangas CC: Kevin Grittner , Craig Ringer , Craig James , Tom Lane , Claudio Freire , Merlin Moncure , David Greco , pgsql-performance@postgresql.org Subject: Re: Hints (was Poor performance using CTE) References: <20121121134232.68590@gmx.com> <50ACFBBD.30204@vmware.com> In-Reply-To: <50ACFBBD.30204@vmware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -0.9 (/) X-Archive-Number: 201211/240 X-Sequence-Number: 48606 On 11/21/2012 08:05 AM, Heikki Linnakangas wrote: > Rather than telling the planner what to do or not to do, I'd much rather > have hints that give the planner more information about the tables and > quals involved in the query. A typical source of bad plans is when the > planner gets its cost estimates wrong. So rather than telling the > planner to use a nested loop join for "a INNER JOIN b ON a.id = b.id", > the user could tell the planner that there are only 10 rows that match > the "a.id = b.id" qual. That gives the planner the information it needs > to choose the right plan on its own. That kind of hints would be much > less implementation specific and much more likely to still be useful, or > at least not outright counter-productive, in a future version with a > smarter planner. > > You could also attach that kind of hints to tables and columns, which > would be more portable and nicer than decorating all queries. I like this idea, but also think that if we have a syntax to allow hints, it would be nice to have a simple way to ignore all hints (yes, I suppose I'm suggesting yet another GUC). That way after sprinkling your SQL with hints, you could easily periodically (e.g. after a Postgres upgrade) test what would happen if the hints were removed. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support