Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group