Re: Slow UPADTE, compared to INSERT
От | Ivar Zarans |
---|---|
Тема | Re: Slow UPADTE, compared to INSERT |
Дата | |
Msg-id | 20031205020728.GA21440@alcaron.ee обсуждение исходный текст |
Ответ на | Re: Slow UPADTE, compared to INSERT (Ivar Zarans <iff@alcaron.ee>) |
Ответы |
Re: Slow UPADTE, compared to INSERT
Re: Slow UPADTE, compared to INSERT |
Список | pgsql-performance |
I have played around with explain and explain analyze and noticed one interesting oddity: === explain UPDATE table1 SET status = 'SKIP' WHERE recid = 196641; Seq Scan on table1 (cost=0.00..16709.97 rows=1 width=199) Filter: (recid = 196641) === explain UPDATE table1 SET status = 'SKIP' WHERE recid = '196641'; Index Scan using table1_pkey on table1 (cost=0.00..6.01 rows=1 width=199) Index Cond: (recid = 196641::bigint) === explain UPDATE table1 SET status = 'SKIP' WHERE recid = 196641::bigint; Index Scan using table1_pkey on table1 (cost=0.00..6.01 rows=1 width=199) Index Cond: (recid = 196641::bigint) === Why first example, where recid is given as numeric constant, is using sequential scan, but second example, where recid is given as string constant works with index scan, as expected? Third example shows, that numeric constant must be typecasted in order to function properly. Is this normal behaviour of fields with bigint type? -- Ivar Zarans
В списке pgsql-performance по дате отправления: