Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 2C9E41337BD3 for ; Wed, 2 Mar 2011 20:12:45 -0400 (AST) 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 15156-09 for ; Thu, 3 Mar 2011 00:12:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mail.postgresql.org (Postfix) with ESMTP id E66DE133616B for ; Wed, 2 Mar 2011 20:12:36 -0400 (AST) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1Puw9k-00070F-4n for pgsql-performance@postgresql.org; Wed, 02 Mar 2011 16:12:36 -0800 Date: Wed, 2 Mar 2011 16:12:36 -0800 (PST) From: sverhagen To: pgsql-performance@postgresql.org Message-ID: <1299111156142-3407330.post@n5.nabble.com> In-Reply-To: <4D6DBC63.7080109@squeakycode.net> References: <1299024855300-3405914.post@n5.nabble.com> <4D6DBC63.7080109@squeakycode.net> Subject: Re: Performance trouble finding records through related records MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.422 tagged_above=-10 required=5 tests=BAYES_00=-1.9, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6, URI_HEX=1.122 X-Spam-Level: X-Archive-Number: 201103/25 X-Sequence-Number: 42704 Thanks for your help already! Hope you're up for some more :-) Andy Colson wrote: > > First off, excellent detail. > > Second, your explain analyze was hard to read... but since you are not > really interested in your posted query, I wont worry about looking at > it... but... have you seen: > > http://explain.depesz.com/ > Thanks for that. Using it below :-) Andy Colson wrote: > > If you run the individual queries, without the union, are the part's slow > too? > Only problem is the second part. So that part can safely be isolated. Also the following does not play a role at this point: WHERE events2.eventtype_id IN (100,103,105,... Then I went ahead and denormalized the transactionId on both ends, so that both events_events records and events_eventdetails records have the transactionId (or NULL). That simplifies the query to this: SELECT events_events.* FROM events_events WHERE transactionid IN ( SELECT transactionid FROM events_eventdetails customerDetails WHERE customerDetails.keyname='customer_id' AND substring(customerDetails.value,0,32)='1957' AND transactionid IS NOT NULL ) ORDER BY id LIMIT 50; To no avail. Also changing the above WHERE IN into implicit/explicit JOIN's doesn't make more than a marginal difference. Should joining not be very efficient somehow? http://explain.depesz.com/s/Pnb The above link nicely shows the hotspots, but I am at a loss now as how to approach them. Andy Colson wrote: > > Looked like your row counts (the estimate vs the actual) were way off, > have you analyzed lately? > Note sure what that means. Isn't all the maintenance nicely automated through my config? Andy Colson wrote: > > I could not tell from the explain analyze if an index was used, but I > notice you have a ton of indexes on events_events table. > Yes, a ton of indexes, but still not the right one :-) -- View this message in context: http://postgresql.1045698.n5.nabble.com/Performance-trouble-finding-records-through-related-records-tp3405914p3407330.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com.