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
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 |