Re: max time in a table query takes ages

On Thu, Oct 23, 2008 at 2:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
>
> I suppose the problem is that rows with processed = false are very few
> in the upper range of data. If so, and if you really need this to go
> fast, a partial index might be worth its overhead:
> create index foo on staticstats(data) where processed = false;

I mostly scan that table for processed=false. Everything with processed =
true is really useless, and there to guard other tables against duplication
(all other tables contain pretty much the same data, but information about
relation isn't stored - because whole structure is quite complicated, and I
need to retrieve data from other tables in matter of miliseconds - I get
live graphs plotted based on huge range of input params, no chance to
pre-render it).
I also thought about create index bar staticstats(data, processed) where
processed = false;
but that would be useful only to that query.
Can postgres use combined indicies for queries that would only require part
of it ?
iow, do I have to create index for every possible combination that can be
used in a query ? what's the best way to do it ?

--
GJ