Re: Heap WARM Tuples - Design Draft
От | Claudio Freire |
---|---|
Тема | Re: Heap WARM Tuples - Design Draft |
Дата | |
Msg-id | CAGTBQpaZ=20xFHZ+MukhmcuG7Q+8FO0qkfVTUjf31WZkoPk3QA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Heap WARM Tuples - Design Draft (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
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).
В списке pgsql-hackers по дате отправления: