Re: Slow UPADTE, compared to INSERT
От | Neil Conway |
---|---|
Тема | Re: Slow UPADTE, compared to INSERT |
Дата | |
Msg-id | 871xrh90ys.fsf@mailbox.samurai.com обсуждение исходный текст |
Ответ на | Re: Slow UPADTE, compared to INSERT (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>) |
Список | pgsql-performance |
Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes: > This is not a bug. It is just that people find it confusing when > postgresql planner consider seemingly same type as different. It certainly is a bug, or at least a deficiency: PostgreSQL planner *could* use the index to process the query, but the planner doesn't consider doing so. The fact that it isn't able to do the necessary type coercion is the *cause* of the bug, not a defence for this behavior. > AFAIK, the fix in CVS is to make indexes operatable with seemingly > compatible types. Which does not change the fact that postgresql can > not upgrade data types on it's own. I'm not sure what you mean by that. In any case, I just checked, and it does seem Tom has fixed this in CVS: template1=# create table abc (b int8); CREATE TABLE template1=# set enable_seqscan = false; SET template1=# create index abc_b_idx on abc (b); CREATE INDEX template1=# explain select * from abc where b = 4; QUERY PLAN ---------------------------------------------------------------------- Index Scan using abc_b_idx on abc (cost=0.00..17.07 rows=5 width=8) Index Cond: (b = 4) (2 rows) Cool! -Neil
В списке pgsql-performance по дате отправления: