From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Cole <cole.jeff@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re:
Date: Mon, 05 Mar 2007 20:54:52 -0500
Message-ID: <25081.1173146092@sss.pgh.pa.us> (raw)
In-Reply-To: <9BAE31C9-93A6-48AE-AFED-3BB1947D13F1@gmail.com>
References: <9BAE31C9-93A6-48AE-AFED-3BB1947D13F1@gmail.com>
Jeff Cole <cole.jeff@gmail.com> writes:
> Hi, I'm new to tuning PostgreSQL and I have a query that gets slower
> after I run a vacuum analyze. I believe it uses a Hash Join before
> the analyze and a Nested Loop IN Join after. It seems the Nested
> Loop IN Join estimates the correct number of rows, but underestimates
> the amount of time required. I am curious why the vacuum analyze
> makes it slower and if that gives any clues as too which parameter I
> should be tuning.
Hm, the cost for the upper nestloop is way less than you would expect
given that the HASH IN join is going to have to be repeated 100+ times.
I think this must be due to a very low "join_in_selectivity" estimate
but I'm not sure why you are getting that, especially seeing that the
rowcount estimates aren't far off. Can you show us the pg_stats
rows for symptoms.id and symptom_reports.symptom_id?
regards, tom lane
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: tgl@sss.pgh.pa.us, cole.jeff@gmail.com
Subject: Re:
In-Reply-To: <25081.1173146092@sss.pgh.pa.us>
* 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