From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Heap WARM Tuples - Design Draft |
Date: | 2016-08-10 02:45:26 |
Message-ID: | CABOikdPJ4U_Oq4EU4UfPAQO+05J+KFoMib+4ZsaVnSiVm84R=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire <klaussfreire(at)gmail(dot)com>
wrote:
> On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
> wrote:
>
> > Some heuristics and limits on amount of work done to detect duplicate
> index
> > entries will help too.
>
> I think I prefer a more thorough approach.
>
> Increment/decrement may get very complicated with custom opclasses,
> for instance. A column-change bitmap won't know how to handle
> funcional indexes, etc.
>
> What I intend to try, is modify btree to allow efficient search of a
> key-ctid pair, by adding the ctid to the sort order.
Yes, that's a good medium term plan. And this is kind of independent from
the core idea. So I'll go ahead and write a patch that implements the core
idea and some basic optimizations. We can then try different approaches
such as tracking changed columns, tracking increment/decrement and teaching
btree to skip duplicate (key, CTID) entries.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2016-08-10 03:03:49 | Re: dsm_unpin_segment |
Previous Message | Jim Nasby | 2016-08-10 02:43:48 | Re: dsm_unpin_segment |