Re: Buffer for inner and outer table

From: Daniel Xavier de Sousa <danielucg(at)yahoo(dot)com(dot)br>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hannu Krosing <hannu(at)skype(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Buffer for inner and outer table
Date: 2006-06-24 21:41:11
Message-ID: 20060624214111.70577.qmail@web52402.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
Please,

Somebody can tell me, where the postgres control the buffer for inner and outer table, when it execute Nest_loop_join? I would want how to change the size this buffer and see all statistics about this

There is another doubt, how can I see the pages access (on Ram and HD) when it execute Nest-loop-join?

Obrigado,
Daniel Xavier de Sousa

Martijn van Oosterhout <kleptog(at)svana(dot)org> escreveu: On Sat, Jun 24, 2006 at 10:04:43PM +0300, Hannu Krosing wrote:
> Maybe we could start from reusing the index tuples which point to
> invisible tuples ? The index is not MVCC anyway, so maybe it is easier
> to do in-place replacement there ?
>
> This probably has the same obstacles which have prevented us from
> removing those in the first place (removing instead of marking as
> invisible). Does it cause some locking issues ? Or does it go against
> some other constraints of our index lookups ?

The problem with updating an index is that you have to do it in a way
that concurrent scans (forwards and backwards) don't get confused
because the tuple they stopped on vanished.

AIUI, the current approach is two step. The first time round you mark
it deleted but don't actually delete it. Thus, any scan currently
stopped on that tuple won't have a problem. Sometime later you remove
the actual tuple, once you know there's no scan stopped on it (because
no scan will deliberatly stop on a deleted tuple).

I forget the actual locking steps that ensure this though.

> If we could delete/reuse old index tuples, it would solve a sizable
> chunk of index-growth problem, especially for cases where referenced key
> value does not change.

I think we recently changed the code to always scan an index a page at
a time so maybe scans no longer stop in the middle of a page anymore...
Or perhaps that was VACUUM only.

Have a noce day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.


---------------------------------
Yahoo! Copa 2006 - cobertura dos jogos em tempo real e tudo sobre a seleção brasileira!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2006-06-24 21:57:20 Re: vacuum, performance, and MVCC
Previous Message Martijn van Oosterhout 2006-06-24 20:52:23 Re: vacuum, performance, and MVCC