Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 353299FA1DA for ; Wed, 18 Oct 2006 19:36:01 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 30466-03 for ; Wed, 18 Oct 2006 22:35:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id E64219F9425 for ; Wed, 18 Oct 2006 19:35:56 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id DAC1956456; Wed, 18 Oct 2006 17:35:55 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 18 Oct 2006 17:35:51 -0500 Date: Wed, 18 Oct 2006 17:35:51 -0500 From: "Jim C. Nasby" To: Jeff Davis Cc: Dimitri Fontaine , pgsql-performance@postgresql.org, Ioana Danes Subject: Re: Postgresql 8.1.4 - performance issues for select on Message-ID: <20061018223551.GD56874@nasby.net> References: <20061018210201.56435.qmail@web55907.mail.re3.yahoo.com> <200610182319.41920.dim@dalibo.com> <1161207230.31645.266.camel@dogma.v10.wvs> <20061018221046.GG85041@nasby.net> <1161210735.31645.277.camel@dogma.v10.wvs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1161210735.31645.277.camel@dogma.v10.wvs> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:061018:pgsql@j-davis.com::mKJhzdvy0/3cEL+V:00000000000000000000 0000000000000000000000009EpU X-Hashcash: 1:20:061018:dim@dalibo.com::j+PaCJ1+xxwh3okl:0000AoU X-Hashcash: 1:20:061018:pgsql-performance@postgresql.org::W4hLyCjrwWnQnmyK:00000 0000000000000000000000001fzY X-Hashcash: 1:20:061018:ioanasoftware@yahoo.ca::p9APElDopPrVqTBy:000000000000000 00000000000000000000000045n5 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200610/385 X-Sequence-Number: 21514 On Wed, Oct 18, 2006 at 03:32:15PM -0700, Jeff Davis wrote: > On Wed, 2006-10-18 at 17:10 -0500, Jim C. Nasby wrote: > > Sorry, don't have the earlier part of this thread, but what about... > > > > SELECT greatest(max(a), max(b)) ... > > > > ? > > To fill you in, we're trying to get the max of a union (a view across > two physical tables). UNION or UNION ALL? You definitely don't want to do a plain UNION if you can possibly avoid it. > It can be done if you're creative with the query; I suggested a query > that selected the max of the max()es of the individual tables. Your > query could work too. However, the trick would be getting postgresql to > recognize that it can transform "SELECT max(x) FROM foo" into that, > where foo is a view of a union. > > If PostgreSQL could sort the result of a union by merging the results of > two index scans, I think the problem would be solved. Is there something > preventing this, or is it just something that needs to be added to the > planner? Hrm... it'd be worth trying the old ORDER BY ... LIMIT 1 trick just to see if that worked in this case, but I don't have much hope for that. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)