Re: Pointers needed on optimizing slow SQL statements

I'm sorry if this is a stupid question, but... I changed
default_statistics_target from the default of 10 to 100, restarted PG,
and then ran "vacuumdb -z" on the database. The plan is exactly the
same as before. Was I supposed to do something else? Do I need to
increase it even further? This is an overloaded system to start with,
so I'm being fairly conservative with what I change.

thanks,

janine

On Jun 3, 2009, at 2:42 PM, Tom Lane wrote:

> Janine Sisk <janine(at)furfly(dot)net> writes:
>> I've been Googling for SQL tuning help for Postgres but the pickings
>> have been rather slim. Maybe I'm using the wrong search terms. I'm
>> trying to improve the performance of the following query and would be
>> grateful for any hints, either directly on the problem at hand, or to
>> resources I can read to find out more about how to do this. In the
>> past I have fixed most problems by adding indexes to get rid of
>> sequential scans, but in this case it appears to be the hash join and
>> the nested loops that are taking up all the time and I don't really
>> know what to do about that. In Google I found mostly references from
>> people wanting to use a hash join to *fix* a performance problem, not
>> deal with it creating one...
>
> The hashjoin isn't creating any problem that I can see. What's
> hurting you is the nestloops above it, which need to be replaced with
> some other join technique. The planner is going for a nestloop
> because
> it expects only one row out of the hashjoin, which is off by more than
> three orders of magnitude :-(. So in short, your problem is poor
> estimation of the selectivity of this condition:
>
>> Join Filter: ((ci.live_revision =
>> cr.revision_id) OR ((ci.live_revision IS NULL) AND (cr.revision_id =
>> content_item__get_latest_revision(ci.item_id))))
>
> It's hard to tell why the estimate is so bad, though, since you didn't
> provide any additional information. Perhaps increasing the statistics
> target for these columns (or the whole database) would help.
>
> regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

---
Janine Sisk
President/CEO of furfly, LLC
503-693-6407