Skip site navigation (1) Skip section navigation (2)

Re: Any better plan for this query?..

From: Chris <dmagick(at)gmail(dot)com>
To: Dimitri <dimitrik(dot)fr(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:22:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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

In response to


pgsql-performance by date

Next:From: DimitriDate: 2009-05-06 08:31:03
Subject: Re: Any better plan for this query?..
Previous:From: Heikki LinnakangasDate: 2009-05-06 08:20:58
Subject: Re: Any better plan for this query?..

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group