On Fri, Jan 19, 2007 at 18:20:47 -0500,
Jeremy Haile <[EMAIL PROTECTED]> wrote:
> That's interesting. So if you have a composite index on two columns, is
> there much of a reason (usually) to create single indexes on each of the
> two columns? I guess the single indexes might be slightly faster
> Rather simple question, of which I'm not sure of the answer.
>
> If I have a multiple column index, say:
> Index index1 on tableA (foo,bar)
>
> and I then:
> Select * from "tableA" where foo =
>
> Will index1 be used, or am I looking at a seqscan in all circumstances?
>
> TIA
> -jan m
R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, it depends.
Given the example from OP, if you have queries that only reference
field bar, then the query optimizer will do a seqscan on the table.
You would need a separate index on "bar"
And, given index1, you do not need another index on "foo
That's interesting. So if you have a composite index on two columns, is
there much of a reason (usually) to create single indexes on each of the
two columns? I guess the single indexes might be slightly faster
depending on the number of different values/combinations, so probably
"it depends" eh?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/19/07 15:53, Jan Muszynski wrote:
> Rather simple question, of which I'm not sure of the answer.
>
> If I have a multiple column index, say:
> Index index1 on tableA (foo,bar)
>
> and I then:
> Select * from "tableA" where foo =
>
> W
Rather simple question, of which I'm not sure of the answer.
If I have a multiple column index, say:
Index index1 on tableA (foo,bar)
and I then:
Select * from "tableA" where foo =
Will index1 be used, or am I looking at a seqscan in all circumstances?
TIA
-jan m
-
