Re: max time in a table query takes ages

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема Re: max time in a table query takes ages
Дата
Msg-id 2f4958ff0810230652m5fcce9dcva0b98cf854eff76b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: max time in a table query takes ages  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: max time in a table query takes ages  (Scott Ribe <scott_ribe@killerbytes.com>)
Список pgsql-general
On Thu, Oct 23, 2008 at 2:47 PM, Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: max time in a table query takes ages
Следующее
От: Jack Orenstein
Дата:
Сообщение: Postgres optimizer choosing wrong index