Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
От | Heikki Linnakangas |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Дата | |
Msg-id | 54E5EF21.4090202@vmware.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 02/16/2015 11:31 AM, Andres Freund wrote: > On 2015-02-16 10:00:24 +0200, Heikki Linnakangas wrote: >> I'm starting to think that we should bite the bullet and consume an infomask >> bit for this. The infomask bits are a scarce resource, but we should use >> them when it makes sense. It would be good for forensic purposes too, to >> leave a trace that a super-deletion happened. > > Well, we IIRC don't have any left right now. We could reuse > MOVED_IN|MOVED_OUT, as that never was set in the past. But it'd > essentially use two infomask bits forever... t_infomask is all used, but t_infomask2 has two bits left: > /* > * information stored in t_infomask2: > */ > #define HEAP_NATTS_MASK 0x07FF /* 11 bits for number of attributes */ > /* bits 0x1800 are available */ > #define HEAP_KEYS_UPDATED 0x2000 /* tuple was updated and key cols > * modified, or tuple deleted */ > #define HEAP_HOT_UPDATED 0x4000 /* tuple was HOT-updated */ > #define HEAP_ONLY_TUPLE 0x8000 /* this is heap-only tuple */ > > #define HEAP2_XACT_MASK 0xE000 /* visibility-related bits */ - Heikki
В списке pgsql-hackers по дате отправления: