| From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Time-correlated columns in large tables |
| Date: | 2007-03-05 20:39:00 |
| Message-ID: | 21077.125.24.218.236.1173127140.squirrel@webmail.xs4all.nl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, March 6, 2007 03:17, Heikki Linnakangas wrote:
> I think you've just described a range-encoded bitmap index. The idea is
> to divide the range of valid values into a some smallish number of
> subranges, and for each of these boundary values you store a bitmap
> where you set the bit representing every tuple with value < boundary
> value.
That's pretty cool! From the looks of it, what you describe would solve
my problem--but using more storage in return for more flexibility. My
scheme really required a correlation between a value and storage order,
which can be pretty fragile. These range-encoded bitmap indexes wouldn't
have that problem.
I guess if you did simple run-length compression on these bitmaps you'd
end up more or less where I came in. But you wouldn't want to flip a bit
somewhere in the middle of a compressed data stream, of course. :-)
Jeroen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2007-03-05 20:45:04 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Tom Lane | 2007-03-05 20:30:28 | Re: Bug: Buffer cache is not scan resistant |