Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 251109FB287 for ; Mon, 30 Apr 2007 14:23:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 51555-06 for ; Mon, 30 Apr 2007 14:23:39 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id DCB359FB1EB for ; Mon, 30 Apr 2007 14:23:39 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr4.postgresql.org (Postfix) with ESMTP id 5D32A5AF02D for ; Mon, 30 Apr 2007 17:23:38 +0000 (GMT) Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1HiZb4-0007qF-6N for pgsql-performance@postgresql.org; Mon, 30 Apr 2007 19:23:34 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1HiZb4-0000Bb-00 for ; Mon, 30 Apr 2007 19:23:34 +0200 Date: Mon, 30 Apr 2007 19:23:34 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Query performance problems with partitioned tables Message-ID: <20070430172334.GA669@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <4635D678.3050205@xss.co.at> <87ps5mgghp.fsf@meuh.mnc.lan> <4635EF3A.1070204@xss.co.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4635EF3A.1070204@xss.co.at> X-Operating-System: Linux 2.6.20.4 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.111 tagged_above=0 required=5 tests=AWL=0.110, BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200704/511 X-Sequence-Number: 24388 On Mon, Apr 30, 2007 at 03:29:30PM +0200, Andreas Haumer wrote: > This already gives a row matching the given WHERE clause. > It makes no sense to scan the other tables, as the query > asks for one row only and all the other tables have timestamps > larger than all the timestamps in table t_mv_200601 (according > to the CHECK constraints for the partion tables) So for each row, it has to check all CHECK constraints to see if it has enough rows? That sounds fairly inefficient. I wonder if the planner could copy the limit down through the Append, though -- it certainly doesn't need more than one row from each partition. It sounds slightly cumbersome to try to plan such a thing, though... /* Steinar */ -- Homepage: http://www.sesse.net/