Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iTmME-0006sx-5b for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Nov 2019 12:30:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iTmMC-0004lO-Cc for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Nov 2019 12:30:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from <9erthalion6@gmail.com>) id 1iTmMB-0004lH-UJ for pgsql-hackers@lists.postgresql.org; Sun, 10 Nov 2019 12:30:16 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1iTmM9-0003qW-Ex for pgsql-hackers@postgresql.org; Sun, 10 Nov 2019 12:30:14 +0000 Received: by mail-wm1-x342.google.com with SMTP id q70so10547990wme.1 for ; Sun, 10 Nov 2019 04:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4/pKOvM3Ng9LnuPnytrdvRxw50Ab5YQVdInnAx9e5e4=; b=XTT0CHuUJhmFGgdBpXtoBv3W9BjBxaivewt39lLtMrFrrnqSYpQRkSahUHRmyVKZY5 CcBNgY7ydywl4xulbwe48e2v7YvzqBtKmvUjw5+oPPjkFdP10KFUb3bxFi+bQNptOuF2 jC5C52HXg55ePKMecsUrLu3Eorevsaedma4IPyPK61aGIlVZCic3p6yy+V+1bYY+/Kyn yRRQuuTKXC+EaRDGX93UiCfYVM+SadsfXDX8Dgt1adUq1xl1xNKqCRjP0McVcP3E/Ts0 gphdMDcoQDrT5zgXayE3xVPehppH58EcFmum9c1sjksbe7YtHG/op4DZFnraZ7QgGBSw w38Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4/pKOvM3Ng9LnuPnytrdvRxw50Ab5YQVdInnAx9e5e4=; b=ACrL9HdB4Oaf6y+/wnJ+9fJlKqRKO2FUeTOgE0haIoWGlpiVoequZ7C3ttqSVxG05F t6VY7KRvrG0ZKeKoYQdAeX46zl8LxZfhuCKemCoAZOuHvsBnp7YmBo3QmUJUuK+EeEBv gWxmPy2TnYpGuVRWFrwXmbTHooQ7bfdLl1HoG+eD2jZV/KnXcSJE+5C9TWAxYV7b+SjZ lR5Nhiz5YxPg9Opsb6gH1XGwiOwB85fKUIbprUdvGCDi03JvVAs6zGxhI5du/6o+LDmv s8PvZNgZCuAwZ1fQGTSAenZo3MDomEn5Z3bWU0ngNJkPOErDQ9JIOdttE8PrC/MGqRzB Ov6w== X-Gm-Message-State: APjAAAW3t36BLQMyZhl6qIKrwPaMZOy++6y70X1i5YQPtRiQ7ypvggLj Cksl6LWmoPDQdZrIRihgY+U= X-Google-Smtp-Source: APXvYqwSFfmPpyah82k9aQxv4BTWOrx60+5EvD3GFkvYARQvdk4fi7zlbkRmJYeX8sLsH/PdqKqBRw== X-Received: by 2002:a1c:6a1a:: with SMTP id f26mr16621048wmc.19.1573389010964; Sun, 10 Nov 2019 04:30:10 -0800 (PST) Received: from localhost (dslb-188-103-189-084.188.103.pools.vodafone-ip.de. [188.103.189.84]) by smtp.gmail.com with ESMTPSA id d20sm26073131wra.4.2019.11.10.04.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Nov 2019 04:30:10 -0800 (PST) Date: Sun, 10 Nov 2019 13:32:08 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Nikita Glukhov Cc: Alvaro Herrera , David Fetter , Thomas Munro , Pavel Stehule , Thomas Munro , Oleksandr Shulgin , Tom Lane , Robert Haas , Andres Freund , Michael Paquier , Oleg Bartunov , Peter Eisentraut , David Steele , PostgreSQL-development Subject: Re: [HACKERS] [PATCH] Generic type subscripting Message-ID: <20191110123208.r4kn5k34wsey5zik@localhost> References: <20190925202205.GA23893@alvherre.pgsql> <099309f0-4b41-2c78-aac8-0835fe9a9ee7@postgrespro.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <099309f0-4b41-2c78-aac8-0835fe9a9ee7@postgrespro.ru> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Thu, Oct 31, 2019 at 05:35:28AM +0300, Nikita Glukhov wrote: > Hi. I added new 5th patch to this patch set. Thank you! > Performance was compared on 4 tables with 10M rows: > > -- [ i ] > CREATE TABLE arr_1 AS > SELECT jsonb_build_array(i)::jsonb js > FROM generate_series(1, 10000000) i; > > -- { "a": i } > CREATE TABLE obj_1 AS > SELECT jsonb_build_object('a', i) js > FROM generate_series(1, 10000000) i; > > -- [[[[[[[[[[ i ]]]]]]]]]] > CREATE TABLE arr_10 AS > SELECT (repeat('[', 10) || i || repeat(']', 10))::jsonb js > FROM generate_series(1, 10000000) i; > > -- {"a": {"a": ... {"a": {"a": i } } ... } } > CREATE TABLE obj_10 AS > SELECT (repeat('{"a":', 10) || i || repeat('}', 10))::jsonb js > FROM generate_series(1, 10000000) i; > > Queries were like "SELECT FROM table WHERE expression IS [NOT] NULL". > > Compared previous v27 version (4 patches) with v28 version (5 patches). > New patch #5 contains one small but important optimization -- elimination of > unnecessary palloc() in getIthJsonbValueFromContainer() and jsonb_get_element(). > It should be posted separately, but for simplicity I included it the patch now. > For the correctness of comparison, it was evaluated separately on top of v27 > (v27opt). > > > Table | Expression | Query time, ms > | | v27 | v27opt| v28 > --------+--------------------------------------+-------+-------+------- > arr_1 | js->0 | 1811 | 1809 | 1813 > arr_1 | js[0] | 2273 | 2294 | 2028 > arr_1 | js['0'] | 2276 | 2286 | 2339 > arr_1 | js->1 | 808 | 844 | 809 > arr_1 | js[1] | 1180 | 1187 | 1008 > obj_1 | js->'a' | 1941 | 1935 | 1939 > obj_1 | js['a'] | 2079 | 2083 | 2102 > obj_1 | js->'b' | 917 | 915 | 902 > obj_1 | js['b'] | 960 | 961 | 1059 > | > arr_10 | js->0->0 ... ->0->0 | 4530 | 4068 | 4052 > arr_10 | js[0][0] ... [0][0] | 6197 | 5513 | 3766 > arr_10 | js['0']['0'] ... ['0']['0'] | 6202 | 5519 | 5983 > arr_10 | js #> '{0,0,0,0,0,0,0,0,0,0}' | 6412 | 5850 | 5835 > arr_10 | js #>> '{0,0,0,0,0,0,0,0,0,0}' | 5904 | 5181 | 5192 > > obj_10 | js->'a'->'a' ... ->'a'->'a' | 4970 | 4717 | 4704 > obj_10 | js['a']['a'] ... ['a']['a'] | 4331 | 3698 | 4032 > obj_10 | js #> '{a,a,a,a,a,a,a,a,a,a}' | 4570 | 3941 | 3949 > obj_10 | js #>> '{a,a,a,a,a,a,a,a,a,a}' | 4055 | 3395 | 3392 > > As it can be seen, array access time reduced from 10% in single subscripts > to 40% in 10-subscript chains, and subscripting event started to overtake > chained "->" operators. But there is 10% slowdown of object key access that > needs further investigation. The elimination of unnecessary palloc()s also > gives good results. I've tested 5th patch a bit and can confirm numbers in the last column for v28 (I've got similar proportions). Let's see what is the reason for 10% of slowdown for object key access. > I had to write new assignment logic reusing only some parts of setPath(), > because the loop in setPath() should be broken on every level. During this > process, I decided to implement assignment behavior similar to PostgreSQL's > array behavior and added two new features: > - creation of jsonb arrays/objects container from NULL values > - appending/prepending array elements on the specified position, gaps filled > with nulls (JavaScript has similar behavior) What is the reason for the last one?