Re: Bitmap index AM - Mailing list pgsql-patches

From Victor Yegorov
Subject Re: Bitmap index AM
Date
Msg-id 20050704231502.GB8828@mits.lv
Whole thread Raw
In response to Bitmap index AM  (Victor Yegorov <viy@mits.lv>)
Responses Re: Bitmap index AM  (Victor Yegorov <viy@mits.lv>)
List 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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [INTERFACES] libecpg (8.0 and CVS) hits a gcc bug on powerpc
Next
From: Neil Conway
Date:
Subject: Re: silence GCC4 warning