| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
| Cc: | Ivar Zarans <iff(at)alcaron(dot)ee>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Slow UPADTE, compared to INSERT |
| Date: | 2003-12-06 19:54:03 |
| Message-ID: | 871xrh90ys.fsf@mailbox.samurai.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Wampler | 2003-12-07 14:28:16 | Re: Help tracking down problem with inserts slowing down... |
| Previous Message | Neil Conway | 2003-12-06 19:41:36 | Re: query using cpu nearly 100%, why? |