From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Johnson, Shaunn" <SJohnson6(at)bcbsm(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: check sql progress |
Date: | 2002-03-01 15:49:46 |
Message-ID: | 28429.1014997786@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Johnson, Shaunn" <SJohnson6(at)bcbsm(dot)com> writes:
> When I do and explain, I get this:
> Nested Loop (cost=0.00..32520.00 rows=10000 width=84)
> -> Seq Scan on t_bp_test1 a (cost=0.00..20.00 rows=1000 width=24)
> -> Seq Scan on t_bp_stage8 b (cost=0.00..20.00 rows=1000 width=60)
> I started the job from last night (about 6pm) and had to
> kill it when I got in this morning (8am). I know the
> data is large (t_bp_stage8 = 8183745 records;
> t_bp_test1 =1677375 records)
The planner evidently doesn't know that. Have you ever done a VACUUM
(perhaps better, VACUUM ANALYZE) on these tables?
Also, I'd suggest simplifying the where clause:
where cast(a.member_id_legacy_cust as char) = b.bp_leg_cust_memb_id;
Can't that be just
where a.member_id_legacy_cust = b.bp_leg_cust_memb_id;
? I think that the added cast will probably prevent the planner from
using any intelligent query plans, like merge or hash join.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Johnson, Shaunn | 2002-03-01 15:52:33 | appending from table to table |
Previous Message | Andrew Sullivan | 2002-03-01 15:20:05 | Re: terminal with horizontal scrollbar |