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/
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
