On Fri, Apr 19, 2019 at 6:34 PM Peter Geoghegan wrote:
> Attached revision does it that way, specifically by adding a new field
> to the insertion scankey struct (BTScanInsertData).
Pushed.
--
Peter Geoghegan
On Thu, Apr 18, 2019 at 8:13 PM Peter Geoghegan wrote:
> It just occurred to me that the final patch will need to be more
> careful about non-key attributes in INCLUDE indexes. It's not okay for
> it to avoid calling _bt_check_unique() just because a non-key
> attribute was NULL. It should only
On Thu, Apr 18, 2019 at 5:46 PM Michael Paquier wrote:
> Adding an open item is adapted, nice you found this issue. Testing on
> my laptop with v11, the non-NULL case takes 5s and the NULL case 6s.
> On HEAD, the non-NULL case takes 6s, and the NULL case takes... I
> just gave up and cancelled
On Wed, Apr 17, 2019 at 07:37:17PM -0700, Peter Geoghegan wrote:
> I'll create an open item for this, and begin work on a patch tomorrow.
Adding an open item is adapted, nice you found this issue. Testing on
my laptop with v11, the non-NULL case takes 5s and the NULL case 6s.
On HEAD, the
On Wed, Apr 17, 2019 at 7:37 PM Peter Geoghegan wrote:
> Tentatively, I think that the fix here is to not "itup_key->scantid =
> NULL" when a NULL value is involved (i.e. don't "itup_key->scantid =
> NULL" when we see IndexTupleHasNulls(itup) within _bt_doinsert()). We
> may also want to avoid
I thought of a case that results in pathological performance due to a
behavior of my nbtree patch series:
regression=# create table uniquenulls(nully int4, constraint pp unique(nully));
CREATE TABLE
Time: 10.694 ms
regression=# insert into uniquenulls select i from generate_series(1, 1e6) i;
