Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 11, 2016 at 11:07 AM, Jim Nasby wrote: > On 8/10/16 12:48 PM, Claudio Freire wrote: >> >> On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby >> wrote: >>> >>> On 8/9/16 6:44 PM, Claudio Freire wrote: Since we can lookup all

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/10/16 12:48 PM, Claudio Freire wrote: On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby wrote: 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

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 9:56 PM, Bruce Momjian wrote: > On Mon, Aug 8, 2016 at 06:34:46PM +0530, Amit Kapila wrote: >> I think here expensive part would be recheck for the cases where the >> index value is changed to a different value (value which doesn't exist >> in WARM

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Wed, Aug 10, 2016 at 4:37 PM, Simon Riggs wrote: > On 10 August 2016 at 03:45, Pavan Deolasee wrote: >> >> >> On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire >> wrote: >>> >>> On Mon, Aug 8, 2016 at 2:52 PM, Pavan

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 10 August 2016 at 03:45, Pavan Deolasee wrote: > > > On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire > wrote: >> >> On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee >> wrote: >> >> > Some heuristics and limits on

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 11:39 PM, Jim Nasby wrote: > 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

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire wrote: > On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee > wrote: > > > Some heuristics and limits on amount of work done to detect duplicate > index > > entries will help too. > > I think I prefer

Re: [HACKERS] Heap WARM Tuples - Design Draft

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

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/9/16 6:46 PM, Claudio Freire wrote: On Tue, Aug 9, 2016 at 8:44 PM, Claudio Freire wrote: index 0 1 2 3 4 k1 .. a a a k2 .. b a a i1 ^ i2 ^ ^ lp u u r3 hot* Sorry, that

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 06:19:57PM -0500, Jim Nasby wrote: > On 8/8/16 3:19 PM, Bruce Momjian wrote: > >>What will help, and something I haven't yet applied any thoughts, is when we > >>> can turn WARM chains back to HOT by removing stale index entries. > >I can't see how we can ever do that

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 8:44 PM, Claudio Freire wrote: > index 0 1 2 3 4 > k1 .. a a a > k2 .. b a a > i1 ^ > i2 ^ ^ > lp u u r3 > hot* Sorry, that should read: index 0 1 2 3

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 8:19 PM, Jim Nasby wrote: > On 8/8/16 3:19 PM, Bruce Momjian wrote: >>> >>> What will help, and something I haven't yet applied any thoughts, is when >>> we >>> > can turn WARM chains back to HOT by removing stale index entries. >> >> I can't see

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/8/16 3:19 PM, Bruce Momjian wrote: What will help, and something I haven't yet applied any thoughts, is when we > can turn WARM chains back to HOT by removing stale index entries. I can't see how we can ever do that because we have multiple indexes pointing to the chain, and keys that

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 5:24 PM, Bruce Momjian wrote: > On Mon, Aug 8, 2016 at 03:36:12PM -0300, Claudio Freire wrote: >> I think I prefer a more thorough approach. >> >> Increment/decrement may get very complicated with custom opclasses, >> for instance. A column-change bitmap

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 03:36:12PM -0300, Claudio Freire wrote: > 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. Hot does HOT handle them?

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 11:22:49PM +0530, Pavan Deolasee wrote: > What I am currently trying to do is to reuse at least the BlockNumber field in > t_ctid. For HOT/WARM chains, that field is really unused (except the last > tuple > when regular update needs to store block number of the new block).

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee wrote: >> >> My guess is we would need one bit to mark a WARM chain, and perhaps >> reuse obsolete pre-9.0 HEAP_MOVED_OFF to indicate increment-only or >> decrement-only. > > > I am not convinced that the checking for

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 11:08 PM, Bruce Momjian wrote: > On Sun, Aug 7, 2016 at 12:55:01PM -0400, Bruce Momjian wrote: > > On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote: > > > OK, crazy idea time --- what if we only do WARM chain additions when > all > > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sun, Aug 7, 2016 at 12:55:01PM -0400, Bruce Momjian wrote: > On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote: > > OK, crazy idea time --- what if we only do WARM chain additions when all > > indexed values are increasing (with NULLs higher than all values)? (If > > a key is

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 06:34:46PM +0530, Amit Kapila wrote: > I think here expensive part would be recheck for the cases where the > index value is changed to a different value (value which doesn't exist > in WARM chain). You anyway have to add the new entry (key,TID) in > index, but each time

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 9:57 AM, Pavan Deolasee wrote: > > > On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire > wrote: >> >> On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote: >> >> > >> > OK, that's a lot of text, and I am

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote: > OK, crazy idea time --- what if we only do WARM chain additions when all > indexed values are increasing (with NULLs higher than all values)? (If > a key is always-increasing, it can't match a previous value in the > chain.) That

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sat, Aug 6, 2016 at 10:51:21AM -0400, Bruce Momjian wrote: > > If we need to find an efficient way to convert WARM chains back to HOT, > > which > > will happen soon when the old index tuple retires, the system can attain a > > stable state, not for all but many use cases. > > I don't see

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sat, Aug 6, 2016 at 10:08:47AM +0530, Pavan Deolasee wrote: > So, we are only checking the index if the WARM chain was pruned, and we > can bail out if there is only one index changed.  This is looking more > doable. > > > The duplicate tuples problem that we are focusing on,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sat, Aug 6, 2016 at 8:34 AM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote: > > So to summarize again: > > > > o chains start out as HOT > > o they become WARM when some indexes change and others don't > > o for multiple index

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote: > So to summarize again: > > o chains start out as HOT > o they become WARM when some indexes change and others don't > o for multiple index changes, we have to check all indexes >for key/ctid matches > o for single index

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:02:39PM -0400, Bruce Momjian wrote: > Yes, it seems we either find the entry fast and avoid the index > addition, or don't find it quickly and use a non-HOT, non-WARM update. > The problem is that you have to do this for multiple indexes, and if you > quickly find you

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:21:49PM -0300, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: > > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: > >> > This does create more HOT chains where the root ctid cannot be removed, > >> > but it

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: >> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: >>> > This does create more HOT chains where the root ctid cannot be removed,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: >> > This does create more HOT chains where the root ctid cannot be removed, >> > but it does avoid the index key/ctid check because any entry in the HOT >> >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: > > This does create more HOT chains where the root ctid cannot be removed, > > but it does avoid the index key/ctid check because any entry in the HOT > > chain has identical keys. What this would not handle is when an entire > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 4:26 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote: >> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: >> >> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: >> >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 03:26:15PM -0400, Bruce Momjian wrote: > > I just don't know how would you do that without delaying/not-doing HOT chain > > prune. As soon as root and intermediate HOT tuples are gone, all > > information is > > lost. You may delay that, but that will defeat the whole

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote: > On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: > > On Fri, Aug  5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > > But doing the WARM chain backtracking and checking for previous > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > > But doing the WARM chain backtracking and checking for previous > > versions with appropriate keys should be enough to support this use > > case too, it

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > But doing the WARM chain backtracking and checking for previous > versions with appropriate keys should be enough to support this use > case too, it just needs to be well optimized to avoid seriously > impacting performance on the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 2:26 PM, Pavan Deolasee wrote: > On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire > wrote: >> >> On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee >> wrote: >> > >> > >> > I don't see why it is hard.

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee > wrote: > > > > > > I don't see why it is hard. Trying to find the index entry for the old > > update row seems odd, and updating an index

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 12:25:39PM -0300, Claudio Freire wrote: > > 2. The existence of index pointers to intermediate tuples will lead to index > > bloat. This is the same problem that we found in Simon's original proposal > > (discussed internally). None of the intermediate line pointers can be

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee wrote: > > > On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire > wrote: >> >> On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote: >> >> > >> > OK, that's a lot of text, and I am

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:57:19AM +0530, Pavan Deolasee wrote: > Hmm. That seems like a real problem. The only way to address that is to ensure > that for a given WARM chain and given index key, there must exists only a > single index entry. There can and will be multiple entries if the index key

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire wrote: > On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote: > > > > > OK, that's a lot of text, and I am confused. Please tell me the > > advantage of having an index point to a string of HOT chains,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 12:44 AM, Bruce Momjian wrote: >> UPDATE t SET dat = dat + 1, id = 3, someid = 3 where id = 2; > > This is ends the WARM chain, and creates new index entries because all > indexes are changed. > >> UPDATE t SET dat = dat + 1, id = 1, someid = 2 where id =

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 11:53:05PM -0300, Claudio Freire wrote: > The point is avoiding duplicate rows in the output of index scans. > > I don't think you can avoid it simply by applying index condition > rechecks as the original proposal implies, in this case: > > CREATE TABLE t (id integer not

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 09:53:31PM -0300, Claudio Freire wrote: >> It's the other way around. A WARM chain has to span whole HOT chains. >> The WARM chain always begins in the head of a HOT chain (or non-HOT >> tuple of

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 09:53:31PM -0300, Claudio Freire wrote: > It's the other way around. A WARM chain has to span whole HOT chains. > The WARM chain always begins in the head of a HOT chain (or non-HOT > tuple of course), and cannot end before the HOT chain ends. > > That is, all within a

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 7:59 AM, Pavan Deolasee wrote: > So marking the index would require us to mark both old and new index tuples > as requiring re-check. That requires an additional index scan to locate the > old row and then an additional write to force it to

Re: [HACKERS] Heap WARM Tuples - Design Draft

>On Thu, Aug 4, 2016 at 06:21:48PM -0400, Bruce Momjian wrote: > Another approach would be to keep updates on the same page in a single > WARM chain, even if all indexes have changed columns. We will already > have code to walk the HOT chain looking for matches, and at most one > tuple in the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 7:21 PM, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 03:23:10PM -0300, Claudio Freire wrote: >> INSERT INTO TABLE t (id,val,dat) VALUES (32,'a','blabla'); >> UPDATE t SET dat='blabla2' where id = 32; >> UPDATE t SET dat='blabla3', id=33 where id = 32;

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 10:58:33PM +0530, Pavan Deolasee wrote: > 2. I also think that most often the tuple that will be updated will have its > t_ctid pointing to itself. This sounds more invasive, but can we somehow Agreed! I think it has to. Great idea. > utilise the t_ctid field to store

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 03:33:16PM -0300, Claudio Freire wrote: > On Thu, Aug 4, 2016 at 3:23 PM, Claudio Freire wrote: > >> That is a new HOT chain given our current code, but > >> would the new tuple addition realize it needs to create a new index > >> tuple? The new

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 03:23:10PM -0300, Claudio Freire wrote: > INSERT INTO TABLE t (id,val,dat) VALUES (32,'a','blabla'); > UPDATE t SET dat='blabla2' where id = 32; > UPDATE t SET dat='blabla3', id=33 where id = 32; > UPDATE t SET val='b' where id = 33; > UPDATE t SET dat='blabla4' where id =

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 3:23 PM, Claudio Freire wrote: >> That is a new HOT chain given our current code, but >> would the new tuple addition realize it needs to create a new index >> tuple? The new tuple code needs to check the index's root HOT tid for a >> non-match. > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 3:07 PM, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 02:35:32PM -0300, Claudio Freire wrote: >> > Vacuum will need to be taught not to break the invariant, but I >> > believe this is viable and efficient. >> >> >> And I didn't mention the invariant. >>

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 02:35:32PM -0300, Claudio Freire wrote: > > Vacuum will need to be taught not to break the invariant, but I > > believe this is viable and efficient. > > > And I didn't mention the invariant. > > The invariant would be that all WARM chains: > > * contain entire HOT

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 01:05:53PM -0400, Bruce Momjian wrote: > > Approach 2 seems more reasonable and simple.  > > > > There are only 2 bits for lp_flags and all combinations are already used. > > But > > for LP_REDIRECT root line pointer, we could use the lp_len field to store > > this > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 11:04:49PM +0530, Pavan Deolasee wrote: > If the root tuple still exists, we store the WARM flag (or > HEAP_RECHECK_REQUIRED as used in the original post) in the tuple header > itself. > When the root tuple becomes dead and HOT prune decides to replace it with a >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 10:49 PM, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 06:16:02PM +0100, Simon Riggs wrote: > > On 4 August 2016 at 18:05, Bruce Momjian wrote: > > > > >> Approach 2 seems more reasonable and simple. > > >> > > >> There are only 2

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 2:14 PM, Claudio Freire wrote: > To fix this, what I was pondering, and I believe it would be viable, > is to teach heap_hot_search_buffer about the WARM invariant. It will > make correctness heavily depend on the invariant being true, which > means

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 10:41 PM, Simon Riggs wrote: > On 4 August 2016 at 17:31, Andres Freund wrote: > > Hi, > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > >> Indexes whose values do not change do not require new index pointers. > Only

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 06:18:47PM +0100, Simon Riggs wrote: > > Have you considered what it'd take to allow index pointers to allow to > > point to "intermediate" root tuples? I.e. have some indexes point into > > the middle of an update-chain, whereas others still point to the > > beginning?

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 2016-08-04 18:18:47 +0100, Simon Riggs wrote: > On 4 August 2016 at 18:17, Andres Freund wrote: > > On 2016-08-04 18:11:17 +0100, Simon Riggs wrote: > > I'm less afraid of the fiddlyness of finding the root tuple, than the > > cost. It's not cheap to walk through,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 06:16:02PM +0100, Simon Riggs wrote: > On 4 August 2016 at 18:05, Bruce Momjian wrote: > > >> Approach 2 seems more reasonable and simple. > >> > >> There are only 2 bits for lp_flags and all combinations are already used. > >> But > >> for LP_REDIRECT

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 4 August 2016 at 18:17, Andres Freund wrote: > On 2016-08-04 18:11:17 +0100, Simon Riggs wrote: >> On 4 August 2016 at 17:31, Andres Freund wrote: >> > Hi, >> > >> > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: >> >> Indexes whose values do not

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 2016-08-04 18:11:17 +0100, Simon Riggs wrote: > On 4 August 2016 at 17:31, Andres Freund wrote: > > Hi, > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > >> Indexes whose values do not change do not require new index pointers. Only > >> the index whose key is

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 09:58:29AM -0700, Andres Freund wrote: > On 2016-08-04 12:55:25 -0400, Bruce Momjian wrote: > > On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote: > > > Hi, > > > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > > > > Indexes whose values do not

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 4 August 2016 at 18:05, Bruce Momjian wrote: >> Approach 2 seems more reasonable and simple. >> >> There are only 2 bits for lp_flags and all combinations are already used. But >> for LP_REDIRECT root line pointer, we could use the lp_len field to store >> this >> special

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 7:59 AM, Pavan Deolasee wrote: > We don’t want to force a recheck for every index fetch because that will > slow everything down. So we would like a simple and efficient way of knowing > about the existence of a WARM tuple in a chain and do a

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 09:58:29AM -0700, Andres Freund wrote: > On 2016-08-04 12:55:25 -0400, Bruce Momjian wrote: > > On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote: > > > Hi, > > > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > > > > Indexes whose values do not

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 4 August 2016 at 17:31, Andres Freund wrote: > Hi, > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: >> Indexes whose values do not change do not require new index pointers. Only >> the index whose key is being changed will need a new index entry. The new >> index

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 04:29:09PM +0530, Pavan Deolasee wrote: > Write Amplification Reduction Method (WARM) > > > A few years back, we developed HOT to address the problem associated with MVCC > and frequent updates and it has served us very well. But in the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 2016-08-04 12:55:25 -0400, Bruce Momjian wrote: > On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote: > > Hi, > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > > > Indexes whose values do not change do not require new index pointers. Only > > > the index whose key is

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Thu, Aug 4, 2016 at 09:31:18AM -0700, Andres Freund wrote: > Hi, > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > > Indexes whose values do not change do not require new index pointers. Only > > the index whose key is being changed will need a new index entry. The new > > index entry

Re: [HACKERS] Heap WARM Tuples - Design Draft

Hi, On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > Indexes whose values do not change do not require new index pointers. Only > the index whose key is being changed will need a new index entry. The new > index entry will be set to the CTID of the root line pointer. That seems to require