Re: Using bitmap index scans-more efficient

From: Kyle Bateman <kyle(at)actarg(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org, Florian Weimer <fweimer(at)bfk(dot)de>
Subject: Re: Using bitmap index scans-more efficient
Date: 2006-08-15 23:15:37
Message-ID: 44E25599.4060905@actarg.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:

>Kyle Bateman <kyle(at)actarg(dot)com> writes:
>
>
>>But I'm assuming that using an interval-encoded project tree, I would
>>have to do something like the following to get a progency group:
>>
>>
>>select * from ledger l, proj p where p.proj_id = l.proj and p.left >
>>1234 and p.right < 2345;
>>
>>

Here's an interesting result:

I created a function proj_left(int4) that returns the left interval
number for a given project. Then I created an index on the underlying
table for the ledger view(which took forever to build) like so:

create index i_test on apinv_items (proj_left(proj));

Now my query:

select * from ledger where proj_left(dr_proj) >= 5283 and
proj_left(dr_proj) < 5300;

is very speedy. Problem is, I had to mark the function proj_left() as
immutable, which it can not be since the left and right values for a
given project will change any time a project is added, removed, or moved
around the hierarchy :(

So is there any good way to tell the planner to do several individual
index scans for the projects involved in the desired progeny, or the
results together and return the result? This is what it seems to be
choosing in the case of the query:

select * from ledger where proj in (4737,4789,4892,4893,4894,4895,4933,4934,4935);

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Markus Schaber 2006-08-16 08:41:09 Re: Undo an update
Previous Message Kyle Bateman 2006-08-15 21:58:39 Re: Using bitmap index scans-more efficient