From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, 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 19:41:04 |
Message-ID: | CAGTBQpaZ=20xFHZ+MukhmcuG7Q+8FO0qkfVTUjf31WZkoPk3QA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 10, 2016 at 4:37 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 10 August 2016 at 03:45, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>>
>>
>> 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.
>
> +1 That seems like a good idea. It would allow us to produce a bitmap
> scan in blocksorted order.
Well, not really. Only equal-key runs will be block-sorted, since the
sort order would be (key, block, offset).
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-08-10 20:02:27 | new pgindent run before branch? |
Previous Message | Shay Rojansky | 2016-08-10 19:39:49 | Re: Slowness of extended protocol |