From: | "Dave Dutcher" <dave(at)tridecap(dot)com> |
---|---|
To: | "'Mario Splivalo'" <msplival(at)jagor(dot)srce(dot)hr>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Lot'sa joins - performance tip-up, please? |
Date: | 2006-05-03 15:20:35 |
Message-ID: | 003001c66ec5$205a0160$8300a8c0@tridecap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> -> Nested Loop (cost=0.00..176144.30 rows=57925 width=26)
> (actual time=68.322..529472.026 rows=57925 loops=1)
> -> Seq Scan on ticketing_codes_played
> (cost=0.00..863.25 rows=57925 width=8) (actual time=0.042..473.881
> rows=57925 loops=1)
> -> Index Scan using ticketing_codes_pk on
> ticketing_codes (cost=0.00..3.01 rows=1 width=18) (actual
> time=9.102..9.108 rows=1 loops=57925)
> Index Cond: (ticketing_codes.code_id =
> "outer".code_id)
> Total runtime: 542000.093 ms
> (27 rows)
>
>
> I'll be more than happy to provide any additional information
> that I may
> be able to gather. I'd be most happy if someone would scream something
> like "four joins, smells like a poor design" because design
> is poor, but
> the system is in production, and I have to bare with it.
It looks like that nested loop which is joining ticketing_codes_played
to ticketing_codes is the slow part. I'm curious how many rows are in
the ticketing_codes table?
Four or five joins does not seem like a lot to me, but it can be slow if
you are joining big tables with other big tables.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2006-05-03 15:59:39 | Re: Slow restoration question |
Previous Message | Jeff Trout | 2006-05-03 14:46:51 | Re: Slow restoration question |