Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
| От | Pavan Deolasee |
|---|---|
| Тема | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
| Дата | |
| Msg-id | CABOikdMHVag0BRwYOaKsU-aBRNuGEZvtjAzeKOGJVURNxcS0HA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
On Thu, Feb 23, 2017 at 11:30 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Feb 1, 2017 at 10:46:45AM +0530, Pavan Deolasee wrote:
> > contains a WARM tuple. Alternate ideas/suggestions and review of the
> design
> > are welcome!
>
> t_infomask2 contains one last unused bit,
>
>
> Umm, WARM is using 2 unused bits from t_infomask2. You mean there is another
> free bit after that too?
We are obviously going to use several heap or item pointer bits for
WARM, and once we do that it is going to be hard to undo that. Pavan,
are you saying you could do more with WARM if you had more bits? Are we
sure we have given you all the bits we can? Do we want to commit to a
lesser feature because the bits are not available?
btree implementation is complete as much as I would like (there are a few TODOs, but no show stoppers), at least for the first release. There is a free bit in btree index tuple header that I could use for chain conversion. In the heap tuples, I can reuse HEAP_MOVED_OFF because that bit will only be set along with HEAP_WARM_TUPLE bit. Since none of the upgraded clusters can have HEAP_WARM_TUPLE bit set, I think we are safe.
WARM currently also supports hash indexes, but there is no free bit left in hash index tuple header. I think I can work around that by using a bit from ip_posid (not yet implemented/tested, but seems doable).
Thanks,
Pavan
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: