From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, bausch(at)dvs(dot)tu-darmstadt(dot)de |
Subject: | Re: [PATCH] bitmap indexes |
Date: | 2013-09-26 15:39:05 |
Message-ID: | CAMkU=1zUjrG=5RRLJSELrmTXXDg177aLy-2264sXXOD7zQiM0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 25, 2013 at 3:20 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>wrote:
> Hi,
>
> Here are some quick items while skimming this patch. I am looking at
> commit 6448de29d from your github repo, branch bmi.
>
> What's with the pg_bitmapindex stuff in pg_namespace.h? It doesn't seem
> to be used anywhere.
>
> This led me to research how these indexes are stored. I note that what
> we're doing here is to create another regular table and a btree index on
> top of it, and those are the ones that actually store the index data.
> This seems grotty and completely unlike the way we do things elsewhere
> (compare GIN indexes which have rbtrees inside them).
+1 on that. I don't know about grottiness, but it certainly seems like it
would deadlock like crazy. Which another product's bitmap indexes are
infamous for, but since we don't need to store visibility information in
our indexes, hopefully we can do better.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-09-26 16:44:28 | Re: FW: REVIEW: Allow formatting in log_line_prefix |
Previous Message | Robert Haas | 2013-09-26 15:18:21 | Re: record identical operator |