To: Mark Fox <mark.fox@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance indexing of a simple query 
In-reply-to: <bca49a9f05082413435f737033@mail.gmail.com> 
References: <bca49a9f05082413435f737033@mail.gmail.com>
Comments: In-reply-to Mark Fox <mark.fox@gmail.com>
	message dated "Wed, 24 Aug 2005 14:43:51 -0600"
Date: Wed, 24 Aug 2005 19:42:00 -0400
Message-ID: <16554.1124926920@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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