Re: bitmap AM design

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [01.03.2005 09:37]:
> The other stuff you mentioned implies that an insertion therefore
> requires exclusive lock on the index (because you may have to relocate
> everything in sight to add one more CTID slot).

No, exclusive lock on index is worst thing to do.

All lists (list of ctids, bitmaps) will only grow, no data will be deleted, as
deletes will require relocation and possibly exclusive lock on the index.

Extending lists will need only a short-term exclusive locks on the pages in
the tails of each list.

> I can't believe you are seriously suggesting that it's OK to force every
> VACUUM to rebuild the index from scratch. We already get far too many
> complaints about the time needed for VACUUM.
>
> I don't think we really need any more fundamentally nonconcurrent index
> types :-(

Well, I misunderstood the purpose of ambulkdelete function, my fault.

Of course, no index rebuild will take place, instead, only flags in the
list of CTIDs will be updated for deleted tuples.

I have counter question for you: you've mentioned, that you want bitmaps in
the 8.1. What kind of bitmaps you were speaking about? On-disk bitmaps (this
is how I call new index access method I'm working on) or in-memory bitmaps,
as in here http://archives.postgresql.org/pgsql-hackers/2005-01/msg01001.php

Thanks for your reply.

--

Victor Y. Yegorov