Re: HOT synced with HEAD

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: HOT synced with HEAD
Date: 2007-09-17 02:29:45
Message-ID: 2e78013d0709161929k44f1446am6303ce5f4e0325fe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 9/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Hmm ... so all that logic to prune just one tuple chain is dead code,
> because heap_page_prune_defrag() ignores its pruneoff argument and
> always passes InvalidOffsetNumber down to heap_page_prune().
>
> While this is certainly a fairly trivial bug, it makes me wonder whether
> the prune-one-chain logic has ever been active and whether there is any
> real evidence for having it at all. Was this error introduced in some
> recent refactoring, or has it always been like that?

This was introduced in the recent refactoring (the whole discussion of
pruning/defragmentation started after that post) Earlier we used to prune
single chain during index scans. In fact, I intentionally left the code that
way because we are still debating the issue and I wanted to keep the
infrastructure there even if there are no users of it right now.

Given the way that
> the logic works now, in particular that we always insist on doing
> defrag, what point is there in not pruning all the chains when we can?
>
>
Yeah, unless we separate pruning and defragmentation, there is
no real value for single chain pruning. Defragmentation is a costly
operation and we would want to prune as many chains before calling
it.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-17 04:02:47 Re: invalidly encoded strings
Previous Message Tom Lane 2007-09-17 01:19:05 Re: HOT synced with HEAD