Skip site navigation (1) Skip section navigation (2)

Re: slow joining very large table to smaller ones

From: John A Meinel <john(at)arbash-meinel(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dan Harris <fbsd(at)drivefaster(dot)net>,pgsql-performance(at)postgresql(dot)org
Subject: Re: slow joining very large table to smaller ones
Date: 2005-07-14 23:39:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane wrote:
> John A Meinel <john(at)arbash-meinel(dot)com> writes:
>>What I don't understand is that the planner is actually estimating that
>>joining against the new table is going to *increase* the number of
>>returned rows.
> It evidently thinks that incidentid in the k_r table is pretty
> nonunique.  We really need to look at the statistics data to
> see what's going on.
> 			regards, tom lane

Okay, sure. What about doing this, then:

SELECT recordtext FROM eventactivity
  JOIN (SELECT DISTINCT incidentid FROM k_r JOIN k_b USING (incidentid)
	 WHERE = ?? AND = ??)
 USING (incidentid)

Since I assume that eventactivity is the only table with "recordtext",
and that you don't get any columns from k_r and k_b, meaning it would be
pointless to get duplicate incidentids.

I may be misunderstanding what the query is trying to do, but depending
on what is in k_r and k_b, is it possible to use a UNIQUE INDEX rather
than just an index on incidentid?

There is also the possibility of
SELECT recordtext FROM eventactivtity
  JOIN (SELECT incidentid FROM k_r WHERE = ??
         UNION SELECT incidentid FROM k_b WHERE = ??)
 USING (incidentid)

But both of these would mean that you don't actually want columns from
k_r or k_b, just a unique list of incident ids.

But first, I agree, we should make sure the pg_stats values are reasonable.


In response to

pgsql-performance by date

Next:From: Alison WintersDate: 2005-07-14 23:42:12
Subject: Re: lots of updates on small table
Previous:From: Tom LaneDate: 2005-07-14 23:30:02
Subject: Re: slow joining very large table to smaller ones

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group