From: | "Leeuw van der, Tim" <tim(dot)leeuwvander(at)nl(dot)unisys(dot)com> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: single index on more than two coulumns a bad thing? |
Date: | 2004-04-04 21:06:11 |
Message-ID: | DD0DC14935B1D211981A00105A1B28DB0C912743@NL-ASD-EXCH-1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Aaron,
> -----Original Message-----
> From: pgsql-performance-owner(at)postgresql(dot)org
> [mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of
> Aaron Werman
> Sent: vrijdag 2 april 2004 13:57
>
>
> another thing that I have all over the place is a hierarchy:
> index on grandfather_table(grandfather)
> index on father_table(grandfather, father)
> index on son_table(grandfather, father, son)
>
It depends on your data-distribution, but I find that in almost all cases it's beneficial to have your indexes the other way round in such cases:
index on grandfather_table(grandfather)
index on father_table(father, grandfather)
index on son_table(son, father, grandfather)
That usually gives a less common, more selective value at the start of the index, making the initial selection in the index smaller.
And AFAIK I don't have to rewrite my queries for that; the planner doesn't care about the order of expressions in the query that are on the same level.
That said, I tend to use 'surrogate keys'; keys generated from sequences or auto-number columns for my tables. It makes the tables less readable, but the indexes remain smaller.
Greetings,
--Tim
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Werman | 2004-04-05 02:09:21 | Re: single index on more than two coulumns a bad thing? |
Previous Message | Gary Doades | 2004-04-04 14:50:22 | Re: PostgreSQL and Linux 2.6 kernel. |