Re: Buffer for inner and outer table - Mailing list pgsql-hackers

Hi,<br /><div class="MsoNormal"><span lang="EN-US" style=""> Please, <br /><br /> Somebody can tell me, where the
postgrescontrol the buffer for inner and outer table, when it execute Nest_loop_join? I would want how to change the
sizethis buffer and see all statistics about this<br />  </span></div><div class="MsoNormal"><span lang="EN-US"
style="">Thereis another doubt, how can I see the pages access (on Ram and HD) when it execute
Nest-loop-join?</span></div><divclass="MsoNormal"><span lang="EN-US" style=""> </span></div><div
class="MsoNormal"><spanlang="EN-US" style="">Obrigado,</span></div><div class="MsoNormal"><span lang="EN-US"
style="">DanielXavier de Sousa</span></div><br /><b><i>Martijn van Oosterhout <kleptog@svana.org></i></b>
escreveu:<blockquoteclass="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left:
5px;">On Sat, Jun 24, 2006 at 10:04:43PM +0300, Hannu Krosing wrote:<br />> Maybe we could start from reusing the
indextuples which point to<br />> invisible tuples ? The index is not MVCC anyway, so maybe it is easier<br />>
todo in-place replacement there ?<br />> <br />> This probably has the same obstacles which have prevented us
from<br/>> removing those in the first place (removing instead of marking as<br />> invisible). Does it cause
somelocking issues ? Or does it go against<br />> some other constraints of our index lookups ?<br /><br />The
problemwith updating an index is that you have to do it in a way<br />that concurrent scans (forwards and backwards)
don'tget confused<br />because the tuple they stopped on vanished.<br /><br />AIUI, the current approach is two step.
Thefirst time round you mark<br />it deleted but don't actually delete it. Thus, any scan currently<br />stopped on
thattuple won't have a problem. Sometime later you remove<br />the actual tuple, once you know there's no scan stopped
onit (because<br />no scan will deliberatly stop on a deleted tuple).<br /><br />I forget the actual locking steps that
ensurethis though.<br /><br />> If we could delete/reuse old index tuples, it would solve a sizable<br />> chunk
ofindex-growth problem, especially for cases where referenced key<br />> value does not change.<br /><br />I think
werecently changed the code to always scan an index a page at<br />a time so maybe scans no longer stop in the middle
ofa page anymore...<br />Or perhaps that was VACUUM only.<br /><br />Have a noce day,<br />-- <br />Martijn van
Oosterhout http://svana.org/kleptog/<br />> From each according to his ability. To each according to his ability to
litigate.<br/></blockquote><br /><p><hr size="1" /><a
href="http://us.rd.yahoo.com/mail/br/tagline/copa/*http://br.esportes.yahoo.com/copa2006/">Yahoo!Copa 2006</a> -
coberturados jogos em tempo real e tudo sobre a seleção brasileira!