Re: optimisation for a table with frequently used query

> again thanks - bit of a noob question I know, but it's good to
> learn :-)

    Well not really since the answer is quite subtle...

    You kave two columns A and B.
    Say you have index on A, and index on B.
    These queries will make direct use of the index :
    A=... or any range on A (BETWEEN <, >, <=, >= etc )
    B=... or any range on B (BETWEEN <, >, <=, >= etc )

    Now if you ask for (A=... AND B=...) or ask for (A=... OR B=...) one
index cannot be used, so postgres uses a bitmap scan to combine the
indexes (read the docs). It is slightly slower than a direct index scan,
but still much faster than not using indexes at all.
    If you had an index on A,B it would have been used directly.

    If one of the two indexes has very poor selectivity (like just a few
different values), bitmap scan will not be optimal. If your indexes have
lots of different values, it will be about as fast as a real index.

    An index on A,B can also do WHERE A=... ORDER BY A,B without actually
doing the sort (it will pick the rows in index order), which is nice for
many things, like getting blog comments in order.