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

Re: planner/optimizer question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-performance(at)postgresql(dot)org
Subject: Re: planner/optimizer question
Date: 2004-05-01 16:21:28
Message-ID: 14614.1083428488@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> writes:
> The moment the heap tuple is updated/deleted the visible-to-all 
> flag needs to be set to false again in all indexes. This is 
> critical,

Exactly.  This gets you out of the hint-bit semantics and into a ton
of interesting problems, such as race conditions.  (Process A determines
that tuple X is visible-to-all, and goes to update the index tuple.
Before it can reacquire lock on the index page, process B updates the
heap tuple and visits the index to clear the flag bit.  Once A obtains
lock it will set the flag bit.  Oops.)

Basically what you are buying into with such a thing is multiple copies
of critical state.  It may be only one bit rather than several words,
but updating it is no less painful than if it were a full copy of the
tuple's commit status.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Dave CramerDate: 2004-05-01 18:50:47
Subject: Re: Wierd context-switching issue on Xeon
Previous:From: Gary DoadesDate: 2004-05-01 12:48:35
Subject: Re: planner/optimizer question

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