Re: Heap WARM Tuples - Design Draft

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Heap WARM Tuples - Design Draft
Date: 2016-08-10 02:39:58
Message-ID: d461d8c9-c126-f1bc-666e-ebdd917a9bfe@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/9/16 6:44 PM, Claudio Freire wrote:
> Since we can lookup all occurrences of k1=a index=0 and k2=a index=0,
> and in fact we probably did so already as part of the update logic

That's a change from what currently happens, right?

The reason I think that's important is that dropping the assumption that
we can't safely re-find index entries from the heap opens up other
optimizations, ones that should be significantly simpler to implement.
The most obvious example being getting rid of full index scans in
vacuum. While that won't help with write amplification, it would reduce
the cost of vacuum enormously. Orders of magnitude wouldn't surprise me
in the least.

If that's indeed a prerequisite to WARM it would be great to get that
groundwork laid early so others could work on other optimizations it
would enable.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-08-10 02:43:48 Re: dsm_unpin_segment
Previous Message Jim Nasby 2016-08-10 02:29:22 Re: Heap WARM Tuples - Design Draft