Re: Any better plan for this query?.. - Mailing list pgsql-performance

From Dimitri
Subject Re: Any better plan for this query?..
Date
Msg-id 5482c80a0905060133u3ce63414vd96322e6234a1410@mail.gmail.com
Whole thread Raw
In response to Re: Any better plan for this query?..  (Chris <dmagick@gmail.com>)
Responses Re: Any better plan for this query?..
Re: Any better plan for this query?..
List 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 by date:

Previous
From: Dimitri
Date:
Subject: Re: Any better plan for this query?..
Next
From: Dimitri
Date:
Subject: Re: Any better plan for this query?..