On Wed, Aug 10, 2016 at 4:37 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 10 August 2016 at 03:45, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
>>
>>
>> On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire <klaussfreire@gmail.com>
>> wrote:
>>>
>>> On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee <pavan.deolasee@gmail.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).
