Re: WIP: Covering + unique indexes.
От | Peter Geoghegan |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | CAH2-Wz=3pjEmDDW+RcPEXAR16aDMOOrVKEWvQBhpb8nPfgf2qg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On Fri, Mar 30, 2018 at 10:39 PM, Peter Geoghegan <pg@bowt.ie> wrote: > It's safe, although I admit that that's a bit hard to see. > Specifically, look at this code in _bt_insert_parent(): > > /* > * Find the parent buffer and get the parent page. > * > * Oops - if we were moved right then we need to change stack item! We > * want to find parent pointing to where we are, right ? - vadim > * 05/27/97 > */ > ItemPointerSet(&(stack->bts_btentry.t_tid), bknum, P_HIKEY); > pbuf = _bt_getstackbuf(rel, stack, BT_WRITE); > > Vadim doesn't seem too sure of why he did it that way. What's clear is > that the offset on all internal pages is always P_HIKEY (that is, 1), > because this is the one and only place where new IndexTuples get > generated for internal pages. That's unambiguous. So how could > BTEntrySame() truly need to care about offset? How could there ever be > an internal page offset that wasn't just P_HIKEY? You can look > yourself, using pg_hexedit or pageinspect. Sorry, I meant this code, right before: /* form an index tuple that points at the new right page */ new_item = CopyIndexTuple(ritem); ItemPointerSet(&(new_item->t_tid), rbknum, P_HIKEY); -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: