Re: PostgreSQL does CAST implicitely between int and adomain derived from int
От | Kevin Grittner |
---|---|
Тема | Re: PostgreSQL does CAST implicitely between int and adomain derived from int |
Дата | |
Msg-id | 4A964B66020000250002A3D8@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: PostgreSQL does CAST implicitely between int and a domain derived from int (Jean-Michel Pouré <jm@poure.com>) |
Ответы |
Re: PostgreSQL does CAST implicitely between int and
adomain derived from int
|
Список | pgsql-performance |
Jean-Michel Pouré<jm@poure.com> wrote: > Still casting. For about the tenth time on the topic -- YOUR PROBLEM HAS NOTHING WHATSOEVER TO DO WITH CASTING! Let that go so you can look for the real problem. Just as an example, look at this closely: test=# create table t2 (c1 int not null primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t2_pkey" for table "t2" CREATE TABLE test=# insert into t2 select * from generate_series(1,10000); INSERT 0 10000 test=# vacuum analyze; VACUUM test=# explain analyze select count(*) from t1 where c1 between 200 and 400; QUERY PLAN ---------------------------------------------------------------------- ------------------------------------------------- Aggregate (cost=12.75..12.76 rows=1 width=0) (actual time=0.764..0.765 rows=1 loops=1) -> Index Scan using t1_pkey on t1 (cost=0.00..12.25 rows=200 width=0) (actual time=0.095..0.470 rows=201 loops=1) Index Cond: (((c1)::integer >= 200) AND ((c1)::integer <= 400)) Total runtime: 0.827 ms (4 rows) The type is always put in there so that you can see what it's doing; it doesn't reflect anything which is actually taking any time. Let it go. -Kevin
В списке pgsql-performance по дате отправления: