Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 101D79FB394 for ; Fri, 29 Sep 2006 12:36:05 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 67183-05 for ; Fri, 29 Sep 2006 12:35:59 -0300 (ADT) 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 E5F729FB391 for ; Fri, 29 Sep 2006 12:35:58 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 1996756427; Fri, 29 Sep 2006 10:35:58 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Fri, 29 Sep 2006 10:35:57 -0500 Date: Fri, 29 Sep 2006 10:35:57 -0500 From: "Jim C. Nasby" To: Ben Cc: pgsql-performance@postgresql.org Subject: Re: any hope for my big query? Message-ID: <20060929153557.GD90915@nasby.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060929:bench@silentmedia.com::lgsDg+g2ND/QLSuP:0000000000000000 0000000000000000000000006YxC X-Hashcash: 1:20:060929:pgsql-performance@postgresql.org::N/XrhO3KKYVmW4PI:00000 0000000000000000000000001Orm X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.053 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200609/431 X-Sequence-Number: 21117 There's no join criteria for umdb.node... is that really what you want? On Thu, Sep 28, 2006 at 03:18:56PM -0700, Ben wrote: > Hey guys, I've got a query that is inherently expensive, because it has to > do some joins against some large tables. But it's currently *very* > expensive (at least for a web app), and I've been struggling in vain all > day to knock the cost down. Annoyingly, the least costly version I've come > up with remains my first attempt, and is the most straight-forward: > > explain select > distinct public.album.id > from > public.album,public.albumjoin,public.track,umdb.node > where > node.dir=2811 > and albumjoin.album = public.album.id > and public.albumjoin.track = public.track.id > and levenshtein(substring(public.track.name for 75), > substring(node.file for 75)) <= 10 > and public.album.id in > (select album from albumjoin group by album having count(*) > between 15 and 25) group by public.album.id > having count(*) >= 5; > > > Unique (cost=991430.53..1013711.74 rows=425772 width=4) > -> GroupAggregate (cost=991430.53..1012647.31 rows=425772 width=4) > Filter: (count(*) >= 5) > -> Sort (cost=991430.53..996373.93 rows=1977360 width=4) > Sort Key: album.id > -> Nested Loop (cost=513549.06..737866.68 rows=1977360 > width=4) > Join Filter: > (levenshtein("substring"(("inner".name)::text, 1, 75), > "substring"("outer".file, 1, 75)) <= 10) > -> Index Scan using node_dir on node > (cost=0.00..3.22 rows=16 width=40) > Index Cond: (dir = 2811) > -> Materialize (cost=513549.06..520153.61 > rows=370755 width=25) > -> Hash Join (cost=271464.72..510281.31 > rows=370755 width=25) > Hash Cond: ("outer".id = "inner".track) > -> Seq Scan on track > (cost=0.00..127872.69 rows=5111469 > width=25) > -> Hash (cost=268726.83..268726.83 > rows=370755 width=8) > -> Hash Join > (cost=150840.51..268726.83 > rows=370755 width=8) > Hash Cond: ("outer".album = > "inner".id) > -> Seq Scan on albumjoin > (cost=0.00..88642.18 > rows=5107318 width=8) > -> Hash > (cost=150763.24..150763.24 > rows=30908 width=8) > -> Hash Join > (cost=127951.57..150763.24 rows=30908 width=8) > Hash Cond: > ("outer".id = > "inner".album) > -> Seq Scan on > album > (cost=0.00..12922.72 rows=425772 width=4) > -> Hash > (cost=127874.30..127874.30 rows=30908 width=4) > -> > HashAggregate (cost=126947.06..127565.22 rows=30908 width=4) > Filter: ((count(*) >= 15) AND (count(*) <= 25)) > -> > Seq > Scan > on > albumjoin (cost=0.00..88642.18 rows=5107318 width=4) > > > I've tried adding a length(public.track.name) index and filtering > public.track to those rows where length(name) is within a few characters > of node.file, but that actually makes the plan more expensive. > > Is there any hope to make things much cheaper? Unfortunately, I can't > filter out anything from the album or albumjoin tables. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)