On Sat, Aug 20, 2011 at 2:51 AM, Gokulakannan Somasundaram < gokul...@gmail.com> wrote:
> On Sat, Aug 20, 2011 at 2:25 AM, Heikki Linnakangas < > heikki.linnakan...@enterprisedb.com> wrote: > >> On 19.08.2011 21:06, Gokulakannan Somasundaram wrote: >> >>> If you are following the same design that Heikki put forward, then there >>> is >>> a problem with it in maintaining the bits in page and the bits in >>> visibility >>> map in sync, which we have already discussed. >>> >> >> Are you referring to this: http://archives.postgresql.** >> org/pgsql-hackers/2010-02/**msg02097.php<http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php>? >> I believe Robert's changes to make the visibility map crash-safe covers >> that. Clearing the bit in the visibility map now happens within the same >> critical section as clearing the flag on the heap page and writing th WAL >> record. >> >> In that case, say a 100 sessions are trying to update records which fall > under the 8000*4 heap pages( i assume 2 bits per visibility map - 8 * 1024 * > 4 exact) covered by one page of visibility map, won't it make the 99 > sessions wait for that visibility map while holding the exclusive lock on > the 99 heap pages? > Are we going to say, that these kind of situations occur very rarely? Or > that the loss of scalability in these situations, is worth the performance > during the read-heavy workloads? > > In any case, making a database going through all these extra overheads, > while they don't even have any index-only scans!!! That definitely should > be given a thought. > > Gokul. > Please consider the update, i mentioned above occurs and changes the visibility bit of the page.
