From: | Joseph Shraibman <jks(at)selectacast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgreSQL(dot)org |
Subject: | Re: order of nested loop |
Date: | 2003-06-17 22:12:26 |
Message-ID: | 3EEF924A.2000305@selectacast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> I would suggest bumping up the statistics target for usertable.podkey
> (see ALTER TABLE SET STATISTICS). Since it's only an int4 column you
> could make the target 100 (instead of the default 10) without much
> cost. That should give substantially finer-grain detail and hopefully
> bring this estimate down out of the stratosphere. Re-analyze the table
> and see what it gets you.
>
Thanks, that seemed to have helped. Now I have this other query:
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=46167.67..81194.20 rows=175858 width=13) (actual time=8807.10..16097.85
rows=249551 loops=1)
Hash Cond: ("outer".userkey = "inner".userkey)
-> Seq Scan on u (cost=0.00..25886.79 rows=175858 width=7) (actual
time=0.10..3329.93 rows=249551 loops=1)
Filter: (podkey = 260)
-> Hash (cost=20167.55..20167.55 rows=637355 width=6) (actual time=8806.36..8806.36
rows=0 loops=1)
-> Seq Scan on d (cost=0.00..20167.55 rows=637355 width=6) (actual
time=28.13..7317.19 rows=638045 loops=1)
Total runtime: 16926.00 msec
(7 rows)
How do I read that? Is it creating a hash out of the data in d, then going through u
doing a join?
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2003-06-17 22:12:51 | Re: Sort memory not being released |
Previous Message | Tom Lane | 2003-06-17 21:38:36 | Re: Sort memory not being released |