Re: Is a better way to have the same result of this

From: Vernon Wu <vernonw(at)gatewaytech(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Is a better way to have the same result of this
Date: 2002-12-06 00:43:58
Message-ID: IHQNQPM3YZVCB1TEBZUPOURPJLGUQ1X.3deff2ce@kimiko
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

12/5/2002 4:18:10 PM, "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> wrote:

>Vernon, just so you know, for multi-column indexes to be useful in
>Postgresql, the columns need to be used in the same order they are
>declared in the index if you are using them for an order by.
>
>select * from table order by sex, age;
>
>could use the index
>
>create column table_sex_age on table (sex,age);
>
>but would not use the index
>
>create column table_age_sex on table (age,sex);
>

I haven't have this case yet, might apply for some queries soon.

>However, the order in a where clause portion doesn't really seem to
>matter, so
>
>select * from table where sex='m' and age>=38
>
>and
>
>select * from table where age>=38 and sex='m'
>
>should both be able to use the index.
>
>also, you can use functional indexes, but the arguments in the where
>clause need the same basic form to be useful. So, if you commonly make a
>select like this:
>
>select * from table where age>50 and age<=59;
>
>then you could make a functional index like :
>
>create index table_age_50_59 on table (age) where age>50 and age<=59;
>
>However, the query
>
>select * from table where age>50 and age<=58;
>
>Wouldn't use that index, since the age <= part doesn't match up. It could
>possible use a generic index on age though, i.e. one like
>
>create index table_age on table (age);
>

I didn't know the functional index. Thanks for the eductional information.

>But that index will be larger than the partial one, and so the planner may
>skip using it and use a seq scan instead. Hard to say until your database
>is populated with some representational test data.
>
>Since these indexes will be only a small fraction of the total data, it
>will often be advantageous to use them with a query.
>
>After you have a set of test data, then you can start looking at tuning
>random page cost and such to make your hardware perform properly for
>individual queries. Well, hope that helps.
>
>

I will do some fine query tuning in the final test phase. Right now, I want to make sure the table design and queries are
on the right track.

That indeed helps.

Thanks,

Vernon

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rod Taylor 2002-12-06 04:11:45 ALTER TABLE .. < ADD | DROP > OIDS
Previous Message scott.marlowe 2002-12-06 00:18:10 Re: Is a better way to have the same result of this