Re: Performance indexing of a simple query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Fox <mark(dot)fox(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance indexing of a simple query
Date: 2005-08-24 23:42:00
Message-ID: 16554.1124926920@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Mark Fox <mark(dot)fox(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message mark 2005-08-25 00:13:20 Re: Caching by Postgres
Previous Message Jim C. Nasby 2005-08-24 21:22:34 Re: Performance indexing of a simple query