Re: Any better plan for this query?..
От | Chris |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 4A0148C3.3070304@gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Dimitri <dimitrik.fr@gmail.com>) |
Ответы |
Re: Any better plan for this query?..
|
Список | 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/
В списке pgsql-performance по дате отправления: