From: sverhagen <sverhagen@wps-nl.com>
To: pgsql-performance@postgresql.org
Subject: Re: Performance trouble finding records through related records
Date: Wed, 2 Mar 2011 16:12:36 -0800 (PST)
Message-ID: <1299111156142-3407330.post@n5.nabble.com> (raw)
In-Reply-To: <4D6DBC63.7080109@squeakycode.net>
References: <1299024855300-3405914.post@n5.nabble.com>
<4D6DBC63.7080109@squeakycode.net>
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-...
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sverhagen@wps-nl.com
Subject: Re: Performance trouble finding records through related records
In-Reply-To: <1299111156142-3407330.post@n5.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox