Re: Best way to scan on-disk bitmaps

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Best way to scan on-disk bitmaps
Date: 2005-05-15 20:11:31
Message-ID: 87vf5k2qrw.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I think it would be easy to change the planner and btree to handle
> this (where "easy" means "I remember where all the skeletons are
> buried"). But I don't know the gist code hardly at all. Can anyone
> offer an informed opinion on whether gist can handle this now, and
> if not what it would take to handle it?

Currently gist indexes only use the first column for page splits, making
multi-key gist indexes basically useless. The problem is it's hard to imagine
an API for a pickSplit function that could handle multi-key indexes with
disparate data types and operator classes. I had an idea of a new way to deal
with gist indexes that simplified the API and side-stepped the whole issue but
you raised concerns that it might be too limiting.

Unfortunately the mailing list archive seems to have missed this discussion.
I've attached three messages from the discussion at the time.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2005-05-15 20:54:49 Re: Best way to scan on-disk bitmaps
Previous Message Tom Lane 2005-05-15 19:27:51 Re: Best way to scan on-disk bitmaps