On Sat, 29 Jan 2005 18:46:44 +, Mike Rylander <[EMAIL PROTECTED]> wrote :
> For on-disk bitmap indexes, yes. I don't see any reason this couldn't
> be done with GiST, perhaps even as a generalization of the index stuff
> in the int_array contrib module.
I was thinking about playing with th
On Sat, Jan 29, 2005 at 01:56:12PM +0200, Victor Y. Yegorov wrote:
> 2) Queries, like "where A = 1" or "where A != 2" will require only 1 scan of
> the index, while "where A < 3" will require 2 stages: 1st create a
> list of
> values lesser then 3, 2nd --- do OR of all bitmaps for that values.
On Sun, 30 Jan 2005 12:15:20 +1100, Neil Conway <[EMAIL PROTECTED]> wrote:
> It might _work_, I just don't see the point. Given an attribute of a
> heap relation that has N distinct values and T tuples, you need to store
>
> - N bitmaps, each of T bits (before compression)
> - T ctids
> - a way to
Mike Rylander wrote:
For the initial example where the index is implemented as a set of
unique keys from the table and a bitmap for each key this would look a
unique index, but with an extra datum at at each index node to hold
the bitmap for that key. If implemented that way an augmented B-Tree
st
On Sun, 30 Jan 2005 11:07:59 +1100, Neil Conway <[EMAIL PROTECTED]> wrote:
> Mike Rylander wrote:
> > For on-disk bitmap indexes, yes. I don't see any reason this couldn't
> > be done with GiST
>
> It might be possible to do it with GiST, but GiST is designed for
> implementing tree-structured in
Mike Rylander wrote:
For on-disk bitmap indexes, yes. I don't see any reason this couldn't
be done with GiST
It might be possible to do it with GiST, but GiST is designed for
implementing tree-structured indexes; I don't think it's the right tool
for the job.
-Neil
---(e
Mike Rylander <[EMAIL PROTECTED]> writes:
> As a side note, wouldn't the in-memory bitmaps pretty much kill the
> need for multicolumn indexes? It seems that they would be able to
> join index scans on the same table, and then there would be no need
> for industrial strength cross-column correlati
* Dawid Kuroczko <[EMAIL PROTECTED]> [29.01.2005 21:25]:
> With in-memory bitmap, the search would start with index a, all
> matching rows would form the bitmap; then the second search
> would go through b index, forming another bitmap. Which then
> would be ANDed with previous bitmap.
Not only
On Sat, 29 Jan 2005 21:54:39 +0200, Victor Yegorov <[EMAIL PROTECTED]> wrote:
> * Dawid Kuroczko <[EMAIL PROTECTED]> [29.01.2005 21:25]:
>
> > With in-memory bitmap, the search would start with index a, all
> > matching rows would form the bitmap; then the second search
> > would go through b inde
On Sat, 29 Jan 2005 18:46:44 +, Mike Rylander <[EMAIL PROTECTED]> wrote:
> As a side note, wouldn't the in-memory bitmaps pretty much kill the
> need for multicolumn indexes? It seems that they would be able to
> join index scans on the same table, and then there would be no need
> for industr
On Sat, 29 Jan 2005 19:41:20 +0200, Victor Y. Yegorov <[EMAIL PROTECTED]> wrote:
> * Paweï Niewiadomski <[EMAIL PROTECTED]> [29.01.2005 17:45]:
> > > I'd like to implement bitmap indexes and want your comments. Here is
> > > an essence of what I've found regarding bitmaps for the last month.
> >
>
* Paweï Niewiadomski <[EMAIL PROTECTED]> [29.01.2005 17:45]:
> > I'd like to implement bitmap indexes and want your comments. Here is
> > an essence of what I've found regarding bitmaps for the last month.
>
> Do you think it would be possible to work on it as a team?
Yes, why not.
But everythin
* Tom Lane <[EMAIL PROTECTED]> [29.01.2005 18:24]:
> "Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> > I remember, Tom Lane suggested on-disk bitmaps
>
> I have suggested no such thing, and in fact believe that the sort of
> index structure you are proposing would be of very little use.
Why? I
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> I remember, Tom Lane suggested on-disk bitmaps
I have suggested no such thing, and in fact believe that the sort of
index structure you are proposing would be of very little use. What
I've been hoping to look into is *in memory* bitmaps used as an
Hello.
I'd like to implement bitmap indexes and want your comments. Here is
an essence of what I've found regarding bitmaps for the last month.
Consider the following table So, the bitmap for attribute A will be the
with 1 attribute A(int2): following:
# | A Val | Bi
15 matches
Mail list logo
