Re: Performance indexing of a simple query - Mailing list pgsql-performance

From Tom Lane
Subject Re: Performance indexing of a simple query
Date
Msg-id 16554.1124926920@sss.pgh.pa.us
Whole thread Raw
In response to Performance indexing of a simple query  (Mark Fox <mark.fox@gmail.com>)
Responses Re: Performance indexing of a simple query  ("Jim C. Nasby" <jnasby@pervasive.com>)
List 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 by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: RAID arrays (and vendors)
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Caching by Postgres