Re: Bitmap index AM

From: Victor Yegorov <viy(at)mits(dot)lv>
To: Postgres Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Bitmap index AM
Date: 2005-07-04 23:15:03
Message-ID: 20050704231502.GB8828@mits.lv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

I've managed to fix all bugs I've met so far.
Attached is an updated patch.

Comments:
o README should be updated to reflect the changes I've done recently;

o I'm still haven't tested ammarkpos and amrestrpos functions --- planner is
choosing Nested Loop all the time and my knowledge of query tuning isn't
that good to force Merge Join usage;

o The main reason no space is freed during ambulkdelete is that that would
make inserts and updates really slow. It would take really small amount of
time to determine free slot in the List-of-CTIDs, but then I'd have to read
and check the majority of bitmap storage pages, as there is no easy way to
determine page where bit at given position belongs (or I don't see it at
the moment).

The cause --- page contains both, plain and compressed blocks. And the
number of tuples one page of bitmap storage covers may significantly vary,
thus I have to check each page to find the one where newly inserted tuple
should belong. And such search should be done for each value in the indexed
attributes domain.

But I'm willing to discuss any opinions and waiting for the feedback.
Maybe we can find a good compromise here.

Thanks!

--

Victor Y. Yegorov

Attachment Content-Type Size
diff-20050705-2.gz application/octet-stream 23.5 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2005-07-05 00:17:52 Re: silence GCC4 warning
Previous Message Andrew Dunstan 2005-07-04 20:06:10 Re: HEAD doesn't cope with libraries in non-default locations