Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id E603F2E01D5 for ; Fri, 7 Dec 2007 16:50:17 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 24255-10 for ; Fri, 7 Dec 2007 16:50:14 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by postgresql.org (Postfix) with ESMTP id 1B7952E00B9 for ; Fri, 7 Dec 2007 16:50:17 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.1/8.14.1) with ESMTP id lB7KoE69026374 for ; Fri, 7 Dec 2007 16:50:14 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.1/8.14.1/Submit) id lB7KkIQG024501 for pgsql-performance@postgresql.org; Fri, 7 Dec 2007 16:46:18 -0400 (AST) (envelope-from news) From: Ron Mayer X-Newsgroups: pgsql.performance Subject: Re: TB-sized databases Date: Fri, 07 Dec 2007 12:46:21 -0800 Organization: Hub.Org Networking Services Lines: 21 Message-ID: <4759B11D.1030201@cheapcomplexdevices.com> References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com> <13851.1196351131@sss.pgh.pa.us> <1196352866.4246.1304.camel@ebony.site> <200712051507.22745.xzilla@users.sourceforge.net> <1196933896.4255.340.camel@ebony.site> <20071206154212.GP5294@mathom.us> <15753.1196957598@sss.pgh.pa.us> <4758A1B8.20501@cheapcomplexdevices.com> <4758C425.3080105@cheapcomplexdevices.com> <10359.1197000850@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org To: Tom Lane User-Agent: Icedove 1.5.0.14pre (X11/20071020) In-Reply-To: <10359.1197000850@sss.pgh.pa.us> To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/104 X-Sequence-Number: 27920 Tom Lane wrote: > Ron Mayer writes: >> Tom Lane wrote: >>> There's something fishy about this --- given that that plan has a lower >>> cost estimate, it should've picked it without any artificial >>> constraints. One final thing I find curious about this is that the estimated number of rows is much closer in the "offset 0" form of the query. Since the logic itself is identical, I would have expected the estimated total number of rows for both forms of this query to be identical. Any reason the two plans estimate a different total number of rows? (explain statements for the two forms of the same query from earlier in the thread here: http://archives.postgresql.org/pgsql-performance/2007-12/msg00088.php )