Re: PostgreSQL does CAST implicitely between int and adomain derived from int

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: Jean-Michel Pouré <jm(at)poure(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL does CAST implicitely between int and adomain derived from int
Date: 2009-08-27 14:01:26
Message-ID: 4A964B66020000250002A3D8@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jean-Michel Pouré<jm(at)poure(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jean-Michel Pouré 2009-08-27 14:14:39 Re: PostgreSQL does CAST implicitely between int and adomain derived from int
Previous Message Jean-Michel Pouré 2009-08-27 13:52:33 Re: PostgreSQL does CAST implicitely between int and a domain derived from int