TEMP TABLE USING PROBLEM

Поиск
Список
Период
Сортировка
От Olcsák József
Тема TEMP TABLE USING PROBLEM
Дата
Msg-id 000801c239f5$00f32260$3c14a8c0@ritek.hu
обсуждение исходный текст
Список pgsql-bugs
Hi all!
 
I have a little problem, when using a temp table ....
 
 explain UPDATE cim SET os_cim_id=-1 FROM T_CNY WHERE cim.cim_id=T_CNY.cim_id;
NOTICE:  QUERY PLAN:
 
Hash Join  (cost=26986.59..44340.35 rows=243969 width=129)
  ->  Seq Scan on t_cny  (cost=0.00..3635.69 rows=243969 width=4)
  ->  Hash  (cost=5961.65..5961.65 rows=254965 width=125)
        ->  Seq Scan on cim  (cost=0.00..5961.65 rows=254965 width=125)
In this case t_cny is a temp table and update runs very very slow ...
 
After I copied t_cny a real table named tcny :
 
select * into tcny from t_cny;
 
explain UPDATE cim SET os_cim_id=-1 FROM TCNY WHERE cim.cim_id=TCNY.cim_id;
 
NOTICE:  QUERY PLAN:
 
Nested Loop  (cost=0.00..3321.34 rows=1000 width=129)
  ->  Seq Scan on tcny  (cost=0.00..20.00 rows=1000 width=4)
  ->  Index Scan using pk_cim on cim  (cost=0.00..3.29 rows=1 width=125)

 
Postgres's query optimizer does not determine a temp table field information ???
 
 
 

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Warren W. Gay VE3WWG"
Дата:
Сообщение: Case bug in SQL Constraint
Следующее
От: Anders Hammarquist
Дата:
Сообщение: Re: Bug #728: Interactions between bytea and character encoding when doing analyze