Re: Any better plan for this query?..

From: Dimitri <dimitrik(dot)fr(at)gmail(dot)com>
To: Chris <dmagick(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-06 08:33:42
Message-ID: 5482c80a0905060133u3ce63414vd96322e6234a1410@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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/
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2009-05-06 08:40:46 Re: Any better plan for this query?..
Previous Message Dimitri 2009-05-06 08:31:03 Re: Any better plan for this query?..