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 occurrences of k1=a index=0 and k2=a index=0,
and
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 logic
That's a change fro
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 chain). You anyway have
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 Deolasee
>>> wrote:
>>>
>>> > Some heuristics and limits on amount of work don
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 amount of work done to detect duplicate
>> > index
>> > entries will help too.
>>
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 currently happens, right?
>
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 a more thorough approach.
>
> Increment/decrement m
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 assumpt
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 should read:
index 0 1
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 becaus
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 4
k1 .. a
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 how we can ever do that beca
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 might
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 won't know how to h
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?
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).
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 increment/decrement adds a lot of
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
> > > indexed values are incre
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 alway
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 t
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 confused. Please tell me the
>> > advantage of having an index point to
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 av
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 how
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, happ
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 changes, we have to check
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 chang
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 nee
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 does avoid the ind
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,
>>> > but it does avoid the index key/ctid
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
>> > chain has identical
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
> > HOT
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:
>> > But doing the WARM chain backtracking
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 purpo
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
> > versions with appropriate
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 just needs to be wel
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 av
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. Trying to find the index entry for the old
>> > update row seems odd, and upd
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 row seems odd, but skipping
> > an index addition fo
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
>
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 confused. Please tell me the
>> > advantage of having an index point to
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
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, rather
> > than a single one? Is the advanta
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 = 3;
>
> This does th
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
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 course), and cannot en
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 sing
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-check, which is
> algorithmical
>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 upd
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;
>> UPDATE t SET val=
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 th
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 tuple code needs to check t
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 = 3
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.
>
> I'm not proposing to cha
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.
>>
>> The invariant wo
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 chai
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
> > sp
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
> LP_REDIRE
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 bits for lp_flags and all combinations a
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 either flagging item poin
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
> >> the index whose key is being changed wi
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? Ther
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, potentially, all hot chains to
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 root line pointer,
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 change do not require new index pointers.
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 being changed will need
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 chang
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 flag, which is not u
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 recheck in only
> those cases, i
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 chang
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 entry will be set to the
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
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 bein
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
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 tr
74 matches
Mail list logo