Re: Best way to scan on-disk bitmaps
Greg Stark <gsstark@mit.edu>
From: Greg Stark <gsstark@mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <gsstark@mit.edu>, Bruce Momjian <pgman@candle.pha.pa.us>, "Victor Y. Yegorov" <viy@mits.lv>, Postgres Hackers <pgsql-hackers@postgresql.org>
Date: 2005-05-15T20:11:31Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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.