From: | Mikael Carneholm <carniz(at)spray(dot)se> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Mikael Carneholm <carniz(at)spray(dot)se> |
Subject: | Re: 335 times faster (!) |
Date: | 2003-02-03 19:23:28 |
Message-ID: | 1044300208007644@lycos-europe.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> ------- Ursprungligt meddelande -------
>
> Från: Mario Weilguni <mweilguni(at)sime(dot)com>
> Datum: Mon, 3 Feb 2003 20:05:48 +0100
>
>try:
>explain select * from enheter where enhetsid = '200178146';
>or
>explain select * from enheter where enhetsid = 200178146::bigint
>
explain select * from enheter where enhetsid = '200178146';
QUERY PLAN ---------------------------------------------------------------------------
Index Scan using pk_enheter on enheter (cost=0.00..4.05 rows=1 width=91)
Index Cond: (enhetsid = 200178146::bigint)
(2 rows)
Strange...using:
200178146::bigint
or
'200178146'
..the query is lightning fast. Since the PK column is of integer type, I don't think it's logical to pass a string-type argument...or am I different than most people on this point? :)
What about third party frameworks (such as Hibernate, eg) - I'm sure they will look at the column datatype and think: 'Oh, it's an integer...I'll pass an integer argument then', which will result in unnecessary poor performance.
What's the cause of this behaviour? Why isn't psql (or the backend) converting integer type arguments into char/string types, if there's this much to gain?
(Sorry for being quite a Pg newbie..have never used Pg for such "heavy" load before)
- Mikael
_____________________________________________________________
Här börjar internet!
Skaffa gratis e-mail och gratis internet på http://www.spray.se
Träffa folk från hela Sverige på ett och samma ställe - http://chat.spray.se/
From | Date | Subject | |
---|---|---|---|
Next Message | greg | 2003-02-03 19:26:11 | Re: DBI driver and transactions |
Previous Message | Linh Luong | 2003-02-03 19:10:18 | missing Pg.pm in Postgres v7.3.1 |