| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | heikki(dot)linnakangas(at)enterprisedb(dot)com, Jayadevan(dot)Maymala(at)ibsplc(dot)com, pgsql-performance(at)postgresql(dot)org, pgsql-performance-owner(at)postgresql(dot)org |
| Subject: | Re: Query performance issue |
| Date: | 2011-09-04 15:18:19 |
| Message-ID: | 12017.1315149499@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Thanks for posting the query and related schema. I tried working
> through it, but I keep coming back to this sort, and wondering how a
> sort can have 1121 rows as input and 2673340321 rows as output. Does
> anyone have any ideas on what could cause that?
Mergejoin rescan. There really are only 1121 rows in the data, but
the parent merge join is pulling them over and over again --- evidently
there are a lot of equal keys in the data. The EXPLAIN ANALYZE
machinery counts each fetch as a new row, even after a mark/restore.
The planner does know about that effect and will penalize merge joins
when it realizes there are a lot of duplicate keys in the input. In
this case I'm thinking that the drastic underestimate of the size of the
other side of the join results in not penalizing the merge enough.
(On the other hand, hash joins don't like equal keys that much either...)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jayadevan | 2011-09-04 18:06:31 | Re: Query performance issue |
| Previous Message | Kevin Grittner | 2011-09-04 14:30:58 | Re: Query performance issue |