Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C62731337B8B for ; Mon, 9 May 2011 08:43:14 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 76432-03 for ; Mon, 9 May 2011 11:43:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id F17381337B6E for ; Mon, 9 May 2011 08:43:06 -0300 (ADT) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M1AL2-1PUbcv3DVg-00tcxu; Mon, 09 May 2011 13:43:06 +0200 Message-ID: <4DC7D3F3.9010002@2ndQuadrant.com> Date: Mon, 09 May 2011 07:45:55 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: indexes ignored when querying the master table References: <4DC46470.20004@refusion.com> In-Reply-To: <4DC46470.20004@refusion.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:iEkliswp4xi7llhTSWKkODouwIj6vh6md8aX6Ayqucm GQ5aoGdiSsF0+g1+PAlJHAJNtsfOhsDTdRr55X9BThsmyGB+OX GeliNpGTE8tm33JnWiGm18WJKIuJwkRehPgume0sR1Py594u00 uocZTVB1H9lhylbKWYd7n1u9QvHFTvQ+Kxr/Q37IC1c4uSc47s CiJ6ABWEOu/ZOs3dJb1wiPjRzhssXRPJJ2alrH5LN4= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201105/77 X-Sequence-Number: 43586 On 05/06/2011 05:13 PM, Thomas Hägi wrote: > the query "SELECT * FROM data.logs ORDER BY re_timestamp DESC LIMIT > 100" does use seq scans on all tables instead of using the existing > indexes which takes ages. when issuing the the same query to one of > the child tables directly ("SELECT * FROM data.logs_2011 ORDER BY > re_timestamp DESC LIMIT 100") the index is used as expected and the > data returned quickly. > Let's see, cut and paste http://archives.postgresql.org/message-id/4DB8CE7D.8030503@2ndquadrant.com and: This is probably the limitation that's fixed in PostgreSQL 9.1 by this commit (following a few others leading up to it): http://archives.postgresql.org/pgsql-committers/2010-11/msg00028.php There was a good example showing what didn't work as expected before (along with an earlier patch that didn't everything the larger 9.1 improvement does) at http://archives.postgresql.org/pgsql-hackers/2009-07/msg01115.php ; "ORDER BY x DESC LIMIT 1" returns the same things as MAX(x). It's a pretty serious issue with the partitioning in earlier versions. I know of multiple people, myself included, who have been compelled to apply this change to an earlier version of PostgreSQL to make larger partitioned databases work correctly. The other option is to manually decompose the queries into ones that target each of the child tables individually, then combine the results, which is no fun either. (Am thinking about a documentation backpatch pointing out this limitation) -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books