Re: Performance indexing of a simple query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance indexing of a simple query
Дата
Msg-id 16554.1124926920@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Performance indexing of a simple query  (Mark Fox <mark.fox@gmail.com>)
Ответы Re: Performance indexing of a simple query  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список pgsql-performance
Mark Fox <mark.fox@gmail.com> writes:
> The sort of queries I want to execute (among others) are like:
> SELECT * FROM jobs
> WHERE completion_time > SOMEDATE AND start_time < SOMEDATE;
> In plain english:  All the jobs that were running at SOMEDATE.

AFAIK there is no good way to do this with btree indexes; the problem
is that it's fundamentally a 2-dimensional query and btrees are
1-dimensional.  There are various hacks you can try if you're willing
to constrain the problem (eg, if you can assume some not-very-large
maximum on the running time of jobs) but in full generality btrees are
just the Wrong Thing.

So what you want to look at is a non-btree index, ie, rtree or gist.
For example, the contrib/seg data type could pretty directly be adapted
to solve this problem, since it can index searches for overlapping
line segments.

The main drawback of these index types in existing releases is that they
are bad on concurrent updates and don't have WAL support.  Both those
things are (allegedly) fixed for GIST in 8.1 ... are you interested in
trying out 8.1beta?

            regards, tom lane

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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: RAID arrays (and vendors)
Следующее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: Caching by Postgres