| From: | Chris <dmagick(at)gmail(dot)com> |
|---|---|
| To: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-06 08:22:27 |
| Message-ID: | 4A0148C3.3070304@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Dimitri wrote:
> Hi Craig,
>
> yes, you detailed very well the problem! :-)
> all those CHAR columns are so just due historical issues :-) as well
> they may contains anything else and not only numbers, that's why..
> Also, all data inside are fixed, so VARCHAR will not save place, or
> what kind of performance issue may we expect with CHAR vs VARCHAR if
> all data have a fixed length?..
None in postgres, but the char/varchar thing may or may not bite you at
some point later - sounds like you have it covered though.
> It's 2 times faster on InnoDB, and as it's just a SELECT query no need
> to go in transaction details :-)
Total runtime: 1.442 ms
(10 rows)
You posted a query that's taking 2/1000's of a second. I don't really
see a performance problem here :)
--
Postgresql & php tutorials
http://www.designmagick.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri | 2009-05-06 08:31:03 | Re: Any better plan for this query?.. |
| Previous Message | Heikki Linnakangas | 2009-05-06 08:20:58 | Re: Any better plan for this query?.. |