Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
Date: 2015-02-19 14:11:45
Message-ID: 54E5EF21.4090202@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2015-02-19 14:44:16 Re: Allow "snapshot too old" error, to prevent bloat
Previous Message Heikki Linnakangas 2015-02-19 13:21:34 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0