Re: Any better plan for this query?..
От | Dimitri |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 5482c80a0905060133u3ce63414vd96322e6234a1410@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Chris <dmagick@gmail.com>) |
Ответы |
Re: Any better plan for this query?..
Re: Any better plan for this query?.. |
Список | pgsql-performance |
Hi Chris, the only problem I see here is it's 2 times slower vs InnoDB, so before I'll say myself it's ok I want to be sure there is nothing else to do.. :-) Rgds, -Dimitri On 5/6/09, Chris <dmagick@gmail.com> wrote: > 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 по дате отправления: