Skip site navigation (1) Skip section navigation (2)

Re: bitmap AM design

From: "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bitmap AM design
Date: 2005-03-01 17:53:14
Message-ID: 20050301175314.GB6315@mits.lv (view raw or flat)
Thread:
Lists: pgsql-hackers
* 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

In response to

Responses

pgsql-hackers by date

Next:From: Matthias SchmidtDate: 2005-03-01 17:57:53
Subject: Re: Where to see the patch queue (was Re: [PATCHES] Patch for Postmaster
Previous:From: Tom LaneDate: 2005-03-01 17:46:15
Subject: Re: mysterious log output

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group