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?..  (Richard Huxton <dev@archonet.com>)
Re: Any better plan for this query?..  (Craig Ringer <craig@postnewspapers.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..