Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJTP3-0004Wk-RX for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Mar 2021 03:51:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lJTP2-0005p9-Bh for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Mar 2021 03:51:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJTP1-0005p1-FC for pgsql-hackers@lists.postgresql.org; Tue, 09 Mar 2021 03:51:24 +0000 Received: from smtp126-122.mail.sohu.com ([111.202.126.122]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lJTOq-0006Gv-Lx for pgsql-hackers@lists.postgresql.org; Tue, 09 Mar 2021 03:51:21 +0000 Received: from xby-pc (unknown [218.2.97.92]) by smtp126-122.mail.sohu.com (Postfix) with ESMTPA id 4Dvh8974CTzL36t; Tue, 9 Mar 2021 11:51:04 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sohu.com; s=mail; t=1615261866; bh=quW7rZeh/K6WmzgibYVZr1mQa7/OsWGUpgkPyRZXaoI=; h=Date:From:To:Cc:Subject:References:From; b=TRNOUqU+ZU831feULKUHBFvoQReo8yKS3kMHE175395QyBkmbouFDSurx/MxrLfdh EZPWHqO5oD8daN7sKMceBFknJhBOk3OZJZDITwZHfuiCktqY8mX3Ae/T8iE30h5O3z SOraPY4Vnul2OoaGslOcWkRUnRWu7YISohpqmQEQ= Date: Tue, 9 Mar 2021 11:51:03 +0800 From: "bucoo@sohu.com" To: tgl Cc: pgsql-hackers Subject: Re: POC: converting Lists into arrays References: <11587.1550975080@sss.pgh.pa.us> X-Priority: 3 X-GUID: E77EE8E2-DEBE-499E-B59A-9EE6576A0AF9 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <202103091117157487575@sohu.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart031157638012_=----" X-Sohu-Gateway: 1 X-Sohu-Antispam-Language: 0 X-Sohu-Antispam-Score: 0.01 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. ------=_001_NextPart031157638012_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGVsbG8sIGhlcmUgc29tZSBtYWNyb3MgZm9yIGxpc3RfbWFrZSwgbm93IHdlIGNhbiB1c2luZw0K bGlzdF9tYWtlKC4uLiksIG5vdCBsaXN0X21ha2UxLzIvMyAuLi4NCg0KI2RlZmluZSBNQUNST19B UkdTKC4uLikgX19WQV9BUkdTX18NCiNkZWZpbmUgTElTVF9NQUtFXzFfKG5hcmdfLCBwb3N0Zml4 XywgLi4uKSBsaXN0X21ha2UgIyMgbmFyZ18gIyMgcG9zdGZpeF8oX19WQV9BUkdTX18pDQojZGVm aW5lIExJU1RfTUFLRV8yXyguLi4pIExJU1RfTUFLRV8xXyhfX1ZBX0FSR1NfXykNCiNkZWZpbmUg TElTVF9NQUtFXzNfKC4uLikgTElTVF9NQUtFXzJfKF9fVkFfQVJHU19fKQ0KDQojZGVmaW5lIGxp c3RfbWFrZSguLi4pIExJU1RfTUFLRV8zXyhNQUNST19BUkdTIFZBX0FSR1NfTkFSR1MoX19WQV9B UkdTX18pLCAvKmVtcHR5Ki8sIF9fVkFfQVJHU19fKQ0KI2RlZmluZSBsaXN0X21ha2VfaW50KC4u LikgTElTVF9NQUtFXzNfKE1BQ1JPX0FSR1MgVkFfQVJHU19OQVJHUyhfX1ZBX0FSR1NfXyksIF9p bnQsIF9fVkFfQVJHU19fKQ0KI2RlZmluZSBsaXN0X21ha2Vfb2lkKC4uLikgTElTVF9NQUtFXzNf KE1BQ1JPX0FSR1MgVkFfQVJHU19OQVJHUyhfX1ZBX0FSR1NfXyksIF9vaWQsIF9fVkFfQVJHU19f KQ0KDQptYWNybyBWQV9BUkdTX05BUkdTIGRlZmluZWQgaW4gYy5oDQoNCkhvdyB0byB3b3JrOg0K Zm9yIGxpc3RfbWFrZV9pbnQoNCw1LDYpDQpzdGVwIDE6IExJU1RfTUFLRV8zXyhNQUNST19BUkdT IFZBX0FSR1NfTkFSR1MoNCw1LDYpLCBfaW50LCA0LDUsNikNCnNldHAgMjogTElTVF9NQUtFXzJf KE1BQ1JPX0FSR1MgKDMpLCBfaW50LCA0LDUsNikNCnN0ZXAgMzogTElTVF9NQUtFXzFfKDMsIF9p bnQsIDQsNSw2KQ0Kc3RlcCA0OiBsaXN0X21ha2UzX2ludCg0LDUsNikNCnN0ZXAgNTogbGlzdF9t YWtlM19pbXBsKFRfSW50TGlzdCwgKChMaXN0Q2VsbCkgey5pbnRfdmFsdWUgPSAoNCl9KSwgKChM aXN0Q2VsbCkgey5pbnRfdmFsdWUgPSAoNSl9KSwgKChMaXN0Q2VsbCkgey5pbnRfdmFsdWUgPSAo Nil9KSkNCg0KT3Igd2UgY2FuIGRlZmluZSBzb21lIHB1YmxpYyBtYWNyb3MsIGxpa2UgdGhpczoN CiNkZWZpbmUgTUFDUk9fQVJHUyguLi4pIF9fVkFfQVJHU19fDQojZGVmaW5lIE1BQ1JPX0NPTUJJ Tl8xKHByZWZpeF8sIGNlbnRlcl8sIHBvc3RmaXhfLCAuLi4pIHByZWZpeF8gIyMgY2VudGVyXyAj IyBwb3N0Zml4XyhfX1ZBX0FSR1NfXykNCiNkZWZpbmUgTUFDUk9fQ09NQklOXzIoLi4uKSBNQUNS T19DT01CSU5fMShfX1ZBX0FSR1NfXykNCiNkZWZpbmUgTUFDUk9fQ09NQklOXzMoLi4uKSBNQUNS T19DT01CSU5fMihfX1ZBX0FSR1NfXykNCg0KI2RlZmluZSBsaXN0X21ha2UoLi4uKSBNQUNST19D T01CSU5fMyhsaXN0X21ha2UsIE1BQ1JPX0FSR1MgVkFfQVJHU19OQVJHUyhfX1ZBX0FSR1NfXyks IC8qZW1wdHkqLywgX19WQV9BUkdTX18pDQojZGVmaW5lIGxpc3RfbWFrZV9pbnQoLi4uKSBNQUNS T19DT01CSU5fMyhsaXN0X21ha2UsIE1BQ1JPX0FSR1MgVkFfQVJHU19OQVJHUyhfX1ZBX0FSR1Nf XyksIF9pbnQsIF9fVkFfQVJHU19fKQ0KI2RlZmluZSBsaXN0X21ha2Vfb2lkKC4uLikgTUFDUk9f Q09NQklOXzMobGlzdF9tYWtlLCBNQUNST19BUkdTIFZBX0FSR1NfTkFSR1MoX19WQV9BUkdTX18p LCBfb2lkLCBfX1ZBX0FSR1NfXykNCg0KDQoNCmJ1Y29vQHNvaHUuY29tDQogDQpGcm9tOiBUb20g TGFuZQ0KRGF0ZTogMjAxOS0wMi0yNCAxMDoyNA0KVG86IHBnc3FsLWhhY2tlcnMNClN1YmplY3Q6 IFBPQzogY29udmVydGluZyBMaXN0cyBpbnRvIGFycmF5cw0KRm9yIHF1aXRlIHNvbWUgeWVhcnMg bm93IHRoZXJlJ3MgYmVlbiBkaXNzYXRpc2ZhY3Rpb24gd2l0aCBvdXIgTGlzdA0KZGF0YSBzdHJ1 Y3R1cmUgaW1wbGVtZW50YXRpb24uICBCZWNhdXNlIGl0IHNlcGFyYXRlbHkgcGFsbG9jJ3MgZWFj aA0KbGlzdCBjZWxsLCBpdCBjaGV3cyB1cCBsb3RzIG9mIG1lbW9yeSwgYW5kIGl0J3Mgbm9uZSB0 b28gY2FjaGUtZnJpZW5kbHkNCmJlY2F1c2UgdGhlIGNlbGxzIGFyZW4ndCBuZWNlc3NhcmlseSBh ZGphY2VudC4gIE1vcmVvdmVyLCBvdXIgdHlwaWNhbA0KdXNhZ2UgaXMgdG8ganVzdCBidWlsZCBh IGxpc3QgYnkgcmVwZWF0ZWQgbGFwcGVuZCdzIGFuZCBuZXZlciBtb2RpZnkgaXQsDQpzbyB0aGF0 IHRoZSBmbGV4aWJpbGl0eSBvZiBoYXZpbmcgc2VwYXJhdGVseSBpbnNlcnRhYmxlL3JlbW92YWJs ZSBsaXN0DQpjZWxscyBpcyB1c3VhbGx5IHdhc3RlZC4NCiANCkV2ZXJ5IHRpbWUgdGhpcyBoYXMg Y29tZSB1cCwgSSd2ZSBvcGluZWQgdGhhdCB0aGUgcmlnaHQgZml4IGlzIHRvIGphY2sNCnVwIHRo ZSBMaXN0IEFQSSBhbmQgZHJpdmUgYSBuZXcgaW1wbGVtZW50YXRpb24gdW5kZXJuZWF0aCwgYXMg d2UgZGlkDQpvbmNlIGJlZm9yZSAoY2YgY29tbWl0IGQwYjQzOTlkODEpLiAgSSB0aG91Z2h0IG1h eWJlIGl0IHdhcyBhYm91dCB0aW1lDQp0byBwcm92aWRlIHNvbWUgZXZpZGVuY2UgZm9yIHRoYXQg cG9zaXRpb24sIHNvIGF0dGFjaGVkIGlzIGEgUE9DIHBhdGNoDQp0aGF0IGNoYW5nZXMgTGlzdHMg aW50byBleHBhbnNpYmxlIGFycmF5cywgd2hpbGUgcHJlc2VydmluZyBtb3N0IG9mDQp0aGVpciBl eGlzdGluZyBBUEkuDQogDQpUaGUgYmlnLXBpY3R1cmUgcGVyZm9ybWFuY2UgY2hhbmdlIGlzIHRo YXQgdGhpcyBtYWtlcyBsaXN0X250aCgpDQphIGNoZWFwIE8oMSkgb3BlcmF0aW9uLCB3aGlsZSBs YXBwZW5kKCkgaXMgc3RpbGwgcHJldHR5IGNoZWFwOw0Kb24gdGhlIGRvd25zaWRlLCBsY29ucygp IGJlY29tZXMgTyhOKSwgYXMgZG9lcyBpbnNlcnRpb24gb3IgZGVsZXRpb24NCmluIHRoZSBtaWRk bGUgb2YgYSBsaXN0LiAgQnV0IHdlIGRvbid0IHVzZSBsY29ucygpIHZlcnkgbXVjaA0KKGFuZCBt YXliZSBhIGxvdCBvZiB0aGUgZXhpc3RpbmcgdXNhZ2VzIGFyZW4ndCByZWFsbHkgbmVjZXNzYXJ5 PyksDQp3aGlsZSBpbnNlcnRpb24vZGVsZXRpb24gaW4gbG9uZyBsaXN0cyBpcyBhIHZhbmlzaGlu Z2x5IGluZnJlcXVlbnQNCm9wZXJhdGlvbi4gIE1lYW53aGlsZSwgbWFraW5nIGxpc3RfbnRoKCkg Y2hlYXAgaXMgYSAqaHVnZSogd2luLg0KIA0KVGhlIG1vc3QgY3JpdGljYWwgdGhpbmcgdGhhdCB3 ZSBsb3NlIGJ5IGRvaW5nIHRoaXMgaXMgdGhhdCB3aGVuIGENCkxpc3QgaXMgbW9kaWZpZWQsIGFs bCBvZiBpdHMgY2VsbHMgbWF5IG5lZWQgdG8gbW92ZSwgd2hpY2ggYnJlYWtzDQphIGxvdCBvZiBj b2RlIHRoYXQgYXNzdW1lcyBpdCBjYW4gaW5zZXJ0IG9yIGRlbGV0ZSBhIGNlbGwgd2hpbGUNCmhh bmdpbmcgb250byBhIHBvaW50ZXIgdG8gYSBuZWFyYnkgY2VsbC4gIEluIGFsbW9zdCBldmVyeSBj YXNlLA0KdGhpcyB0YWtlcyB0aGUgZm9ybSBvZiBkb2luZyBsaXN0IGluc2VydGlvbnMgb3IgZGVs ZXRpb25zIGluc2lkZQ0KYSBmb3JlYWNoKCkgbG9vcCwgYW5kIHRoZSBwb2ludGVyIHRoYXQncyBp bnZhbGlkYXRlZCBpcyB0aGUgbG9vcCdzDQpjdXJyZW50LWNlbGwgcG9pbnRlci4gIEZvcnR1bmF0 ZWx5LCB3aXRoIGxpc3RfbnRoKCkgbm93IGJlaW5nIHNvIGNoZWFwLA0Kd2UgY2FuIHJlcGxhY2Ug dGhlc2UgdXNlcyBvZiBmb3JlYWNoKCkgd2l0aCBsb29wcyB1c2luZyBhbiBpbnRlZ2VyDQppbmRl eCB2YXJpYWJsZSBhbmQgZmV0Y2hpbmcgdGhlIG5leHQgbGlzdCBlbGVtZW50IGRpcmVjdGx5IHdp dGgNCmxpc3RfbnRoKCkuICBNb3N0IG9mIHRoZXNlIHBsYWNlcyB3ZXJlIGxvb3BzIGFyb3VuZCBs aXN0X2RlbGV0ZV9jZWxsDQpjYWxscywgd2hpY2ggSSByZXBsYWNlZCB3aXRoIGEgbmV3IGZ1bmN0 aW9uIGxpc3RfZGVsZXRlX250aF9jZWxsDQp0byBnbyBhbG9uZyB3aXRoIHRoZSBlbXBoYXNpcyBv biB0aGUgaW50ZWdlciBpbmRleC4NCiANCkkgZG9uJ3QgY2xhaW0gdG8gaGF2ZSBmb3VuZCBldmVy eSBjYXNlIHdoZXJlIHRoYXQgY291bGQgaGFwcGVuLA0KYWx0aG91Z2ggSSBhZGRlZCBkZWJ1ZyBz dXBwb3J0IGluIGxpc3QuYyB0byBmb3JjZSBsaXN0IGNvbnRlbnRzDQp0byBtb3ZlIG9uIGV2ZXJ5 IGxpc3QgbW9kaWZpY2F0aW9uLCBhbmQgdGhpcyBwYXRjaCBkb2VzIHBhc3MNCmNoZWNrLXdvcmxk IHdpdGggdGhhdCBzdXBwb3J0IHR1cm5lZCBvbi4gIEkgZmVhciB0aGF0IHNvbWUgc3VjaA0KYnVn cyByZW1haW4sIHRob3VnaC4NCiANClRoZXJlIGlzIG9uZSBiaWcgd2F5IGluIHdoaWNoIEkgZmFp bGVkIHRvIHByZXNlcnZlIHRoZSBvbGQgQVBJDQpzeW50YWN0aWNhbGx5OiBsbmV4dCgpIG5vdyBy ZXF1aXJlcyBhIHBvaW50ZXIgdG8gdGhlIExpc3QgYXMNCndlbGwgYXMgdGhlIGN1cnJlbnQgTGlz dENlbGwsIHNvIHRoYXQgaXQgY2FuIGZpZ3VyZSBvdXQgd2hlcmUNCnRoZSBlbmQgb2YgdGhlIGNl bGwgYXJyYXkgaXMuICBUaGF0IHJlcXVpcmVzIHRvdWNoaW5nIHNvbWV0aGluZw0KbGlrZSAxNTAg cGxhY2VzIHRoYXQgb3RoZXJ3aXNlIHdvdWxkbid0IGhhdmUgaGFkIHRvIGJlIHRvdWNoZWQsDQp3 aGljaCBpcyBhbm5veWluZywgZXZlbiB0aG91Z2ggbW9zdCBvZiB0aG9zZSBjaGFuZ2VzIGFyZSB0 cml2aWFsLg0KIA0KSSB0aG91Z2h0IGFib3V0IGF2b2lkaW5nIHRoYXQgYnkgcmVxdWlyaW5nIExp c3RzIHRvIGtlZXAgYSAic2VudGluZWwiDQp2YWx1ZSBpbiB0aGUgY2VsbCBhZnRlciB0aGUgZW5k IG9mIHRoZSBhY3RpdmUgYXJyYXksIHNvIHRoYXQgbG5leHQoKQ0KY291bGQgbG9vayBmb3IgdGhl IHNlbnRpbmVsIHRvIGRldGVjdCBsaXN0IGVuZC4gIEhvd2V2ZXIsIHRoYXQgaWRlYQ0KZG9lc24n dCByZWFsbHkgd29yaywgYmVjYXVzZSBpZiB0aGUgbGlzdCBhcnJheSBoYXMgYmVlbiBtb3ZlZCwg dGhlDQpzcG90IHdoZXJlIHRoZSBzZW50aW5lbCBoYWQgYmVlbiBjb3VsZCBoYXZlIGJlZW4gcmVh bGxvY2F0ZWQgYW5kDQpmaWxsZWQgd2l0aCBzb21ldGhpbmcgZWxzZS4gIFNvIHRoaXMnZCBvZmZl ciBubyBkZWZlbnNlIGFnYWluc3QgdGhlDQpwb3NzaWJpbGl0eSBvZiBhIHN0YWxlIExpc3RDZWxs IHBvaW50ZXIsIHdoaWNoIGlzIHNvbWV0aGluZyB0aGF0DQp3ZSBhYnNvbHV0ZWx5IG5lZWQgZGVm ZW5zZXMgZm9yLiAgQXMgdGhlIHBhdGNoIHN0YW5kcyB3ZSBjYW4gaGF2ZQ0KcXVpdGUgYSBzdHJv bmcgZGVmZW5zZSwgYmVjYXVzZSB3ZSBjYW4gY2hlY2sgd2hldGhlciB0aGUgcHJlc2VudGVkDQpM aXN0Q2VsbCBwb2ludGVyIGFjdHVhbGx5IHBvaW50cyBpbnRvIHRoZSBsaXN0J3MgY3VycmVudCBk YXRhIGFycmF5Lg0KIA0KQW5vdGhlciBhbm5veWluZyBjb25zZXF1ZW5jZSBvZiBsbmV4dCgpIG5l ZWRpbmcgYSBMaXN0IHBvaW50ZXIgaXMgdGhhdA0KdGhlIExpc3QgYXJndW1lbnRzIG9mIGZvcmVh Y2goKSBhbmQgcmVsYXRlZCBtYWNyb3MgYXJlIG5vdyBldmFsdWF0ZWQNCmVhY2ggdGltZSB0aHJv dWdoIHRoZSBsb29wLiAgSSBjb3VsZCBvbmx5IGZpbmQgaGFsZiBhIGRvemVuIHBsYWNlcw0Kd2hl cmUgdGhhdCB3YXMgYWN0dWFsbHkgdW5zYWZlIChhbGwgZml4ZWQgaW4gdGhlIGRyYWZ0IHBhdGNo KSwgYnV0DQppdCdzIHN0aWxsIGJvdGhlcnNvbWUuICBJIGV4cGVyaW1lbnRlZCB3aXRoIHdheXMg dG8gYXZvaWQgdGhhdCwgYnV0DQp0aGUgb25seSB3YXkgSSBjb3VsZCBnZXQgaXQgdG8gd29yayB3 YXMgdG8gZGVmaW5lIGZvcmVhY2ggbGlrZSB0aGlzOg0KIA0KI2RlZmluZSBmb3JlYWNoKGNlbGws IGwpICAgICAgICBmb3IgKGNvbnN0IExpc3QgKmNlbGwjI19fZm9yZWFjaCA9IGZvcmVhY2hfc2V0 dXAobCwgJmNlbGwpOyAgICAgICAgICBjZWxsICE9IE5VTEw7IGNlbGwgPSBsbmV4dChjZWxsIyNf X2ZvcmVhY2gsIGNlbGwpKQ0KIA0Kc3RhdGljIGlubGluZSBjb25zdCBMaXN0ICoNCmZvcmVhY2hf c2V0dXAoY29uc3QgTGlzdCAqbCwgTGlzdENlbGwgKipjZWxsKQ0Kew0KICAgICpjZWxsID0gbGlz dF9oZWFkKGwpOw0KICAgIHJldHVybiBsOw0KfQ0KIA0KVGhhdCB3b3JrcywgYnV0IHRoZXJlIGFy ZSB0d28gcHJvYmxlbXMuICBUaGUgbGVzc2VyIG9uZSBpcyB0aGF0IGENCm5vdC12ZXJ5LWJyaWdo dCBjb21waWxlciBtaWdodCB0aGluayB0aGF0IHRoZSAiY2VsbCIgdmFyaWFibGUgaGFzIHRvDQpi ZSBmb3JjZWQgaW50byBtZW1vcnksIGJlY2F1c2UgaXRzIGFkZHJlc3MgaXMgdGFrZW4uICBUaGUg YmlnZ2VyIG9uZSBpcw0KdGhhdCB0aGlzIGNvZGluZyBmb3JjZXMgdGhlICJjZWxsIiB2YXJpYWJs ZSB0byBiZSBleGFjdGx5ICJMaXN0Q2VsbCAqIjsNCnlvdSBjYW4ndCBhZGQgY29uc3Qgb3Igdm9s YXRpbGUgcXVhbGlmaWVycyB0byBpdCB3aXRob3V0IGdldHRpbmcNCmNvbXBpbGVyIHdhcm5pbmdz LiAgVGhlcmUgYXJlIGFjdHVhbGx5IG1vcmUgcGxhY2VzIHRoYXQnZCBiZSBhZmZlY3RlZA0KYnkg dGhhdCB0aGFuIGJ5IHRoZSBuZWVkIHRvIGF2b2lkIG11bHRpcGxlIGV2YWx1YXRpb25zLiAgSSBk b24ndCB0aGluaw0KdGhlIGNvbnN0IG1hcmtpbmdzIHdvdWxkIGJlIGEgYmlnIGRlYWwgdG8gbG9z ZSwgYW5kIHRoZSB0d28gcGxhY2VzIGluDQpkb19hdXRvdmFjdXVtIHRoYXQgbmVlZCAidm9sYXRp bGUiIChiZWNhdXNlIG9mIGEgbmVhcmJ5IFBHX1RSWSkgY291bGQNCmJlIHJld3JpdHRlbiB0byBu b3QgdXNlIGZvcmVhY2guICBTbyBJJ20gdGVtcHRlZCB0byBkbyB0aGF0LCBidXQgaXQncw0Kbm90 IHZlcnkgcHJldHR5LiAgTWF5YmUgc29tZWJvZHkgY2FuIHRoaW5rIG9mIGEgYmV0dGVyIHNvbHV0 aW9uPw0KIA0KVGhlcmUncyBhIGxvdCBvZiBwb3RlbnRpYWwgZm9sbG93LW9uIHdvcmsgdGhhdCBJ J3ZlIG5vdCB0b3VjaGVkIHlldDoNCiANCjEuIFRoaXMgc3RpbGwgaW52b2x2ZXMgYXQgbGVhc3Qg dHdvIHBhbGxvYydzIGZvciBldmVyeSBub25lbXB0eSBMaXN0LA0KYmVjYXVzZSBJIGtlcHQgdGhl IGhlYWRlciBhbmQgdGhlIGRhdGEgYXJyYXkgc2VwYXJhdGUuICBQZXJoYXBzIGl0J3MNCndvcnRo IGFsbG9jYXRpbmcgdGhvc2UgaW4gb25lIHBhbGxvYy4gIEhvd2V2ZXIsIHJpZ2h0IG5vdyB0aGVy ZSdzIGFuDQphc3N1bXB0aW9uIHRoYXQgdGhlIGhlYWRlciBvZiBhIG5vbmVtcHR5IExpc3QgZG9l c24ndCBtb3ZlIHdoZW4geW91DQpjaGFuZ2UgaXRzIGNvbnRlbnRzOyB0aGF0J3MgZW1iZWRkZWQg aW4gdGhlIEFQSSBvZiB0aGUgbGFwcGVuZF9jZWxsDQpmdW5jdGlvbnMsIGFuZCBtb3JlIHRoYW4g bGlrZWx5IHRoZXJlJ3MgY29kZSB0aGF0IGRlcGVuZHMgb24gdGhhdA0Kc2lsZW50bHkgYmVjYXVz ZSBpdCBkb2Vzbid0IGJvdGhlciB0byBzdG9yZSB0aGUgcmVzdWx0cyBvZiBvdGhlcg0KTGlzdCBm dW5jdGlvbnMgYmFjayBpbnRvIHRoZSBhcHByb3ByaWF0ZSBwb2ludGVyLiAgU28gaWYgd2UgZG8g dGhhdA0KYXQgYWxsIEkgdGhpbmsgaXQnZCBiZSBiZXR0ZXIgdGFja2xlZCBpbiBhIHNlcGFyYXRl IHBhdGNoOyBhbmQgSSdtDQpub3QgcmVhbGx5IGNvbnZpbmNlZCBpdCdzIHdvcnRoIHRoZSB0cm91 YmxlIGFuZCBleHRyYSByaXNrIG9mIGJ1Z3MuDQogDQoyLiBsaXN0X3Fzb3J0KCkgaXMgbm93IGFi c29sdXRlbHkgc3R1cGlkbHkgZGVmaW5lZC4gIEl0IHNob3VsZCBqdXN0DQpxc29ydCB0aGUgbGlz dCdzIGRhdGEgYXJyYXkgaW4tcGxhY2UuICBCdXQgdGhhdCByZXF1aXJlcyBhbiBBUEkNCmJyZWFr IGZvciB0aGUgY2FsbGVyLXN1cHBsaWVkIGNvbXBhcmF0b3IsIHNpbmNlIHRoZXJlJ2QgYmUgb25l IGxlc3MNCmxldmVsIG9mIGluZGlyZWN0aW9uLiAgSSB0aGluayB3ZSBzaG91bGQgY2hhbmdlIHRo aXMsIGJ1dCBhZ2FpbiBpdCdkDQpiZSBiZXR0ZXIgZG9uZSBhcyBhbiBpbmRlcGVuZGVudCBwYXRj aCB0byBtYWtlIGl0IG1vcmUgdmlzaWJsZSBpbiB0aGUNCmdpdCBoaXN0b3J5Lg0KIA0KMy4gVGhl cmUgYXJlIGEgbnVtYmVyIG9mIHBsYWNlcyB3aGVyZSB3ZSd2ZSBidWlsdCBmbGF0IGFycmF5cw0K cGFyYWxsZWxpbmcgTGlzdHMsIHN1Y2ggYXMgdGhlIHBsYW5uZXIncyBzaW1wbGVfcnRlX2FycmF5 LiAgVGhhdCdzDQpwb2ludGxlc3Mgbm93IGFuZCBjb3VsZCBiZSB1bmRvbmUsIGJ1eWluZyBzb21l IGNvZGUgc2ltcGxpY2l0eS4NClZhcmlvdXMgb3RoZXIgbWljcm8tb3B0aW1pemF0aW9ucyBjb3Vs ZCBkb3VidGxlc3MgYmUgZG9uZSB0b287DQpJJ3ZlIG5vdCBsb29rZWQgaGFyZC4NCiANCkkgaGF2 ZW4ndCBhdHRlbXB0ZWQgYW55IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50cyBvbiB0aGlzLCBidXQg YXQNCmxlYXN0IGluIHByaW5jaXBsZSBpdCBzaG91bGQgc3BlZWQgdGhpbmdzIHVwIGEgYml0LCBl c3BlY2lhbGx5DQpmb3IgY29tcGxleCB0ZXN0IGNhc2VzIGludm9sdmluZyBsb25nZXIgTGlzdHMu ICBJIGRvbid0IGhhdmUgYW55DQp2ZXJ5IHN1aXRhYmxlIHRlc3QgY2FzZXMgYXQgaGFuZCwgYW55 d2F5Lg0KIA0KSSB0aGluayB0aGlzIGlzIHRvbyBsYXRlIGZvciB2MTIsIGJvdGggYmVjYXVzZSBv ZiB0aGUgc2l6ZSBvZiB0aGUNCnBhdGNoIGFuZCBiZWNhdXNlIG9mIHRoZSBsaWtlbGlob29kIHRo YXQgaXQgaW50cm9kdWNlcyBhIGZldyBidWdzLg0KSSdkIGxpa2UgdG8gY29uc2lkZXIgcHVzaGlu ZyBpdCBlYXJseSBpbiB0aGUgdjEzIGN5Y2xlLCB0aG91Z2guDQogDQpyZWdhcmRzLCB0b20gbGFu ZQ0KIA0K ------=_001_NextPart031157638012_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0A
Hello, here some macros for list_make, now we can using
list_make(...), not list_make1/2/3 ...

#de= fine MACRO_ARGS(...) __VA_ARGS__
#define LIST_MAKE_1_(narg_, pos= tfix_, ...) list_make ## narg_ ## postfix_(__VA_ARGS__)
#define LIST_MAKE_= 2_(...) LIST_MAKE_1_(__VA_ARGS__)
#define LIST_MAKE_3_(...) LIST= _MAKE_2_(__VA_ARGS__)

#define list_make(...) LIST_MAKE_3_(= MACRO_ARGS VA_ARGS_NARGS(__VA_ARGS__), /*empty*/, __VA_ARGS__)
#= define list_make_int(...) LIST_MAKE_3_(MACRO_ARGS VA_ARGS_NARGS(__VA_ARGS__), _int, = __VA_ARGS__)
#define list_make_oid(...) LIST_MAKE_3_(MACRO_ARGS VA_ARGS_NA= RGS(__VA_ARGS__), _oid, __VA_ARGS__)

macro = VA_ARGS_NARGS defined in c.h

How to work:
for list_make_int(4,5,6)
step 1: LIST_MAKE_3_(MACRO_ARGS = ;VA_ARGS_= NARGS(4,5,6), _int, 4,5,6)
setp 2: LIST_MAKE_2_(MACRO_ARGS = (3), _int, 4,5,6)
step 3: LIST_MAKE_1_(3, _int, 4,5,6)
step 4: list_make3_int(4,5,6)
step 5: list_make3_impl(T_IntList= , ((ListCell) {.int_value =3D (4)}), ((ListCell) {.int_value =3D (5)}), ((= ListCell) {.int_value =3D (6)}))

Or we can define= some public macros, like this:
#define MACRO_ARGS(...) __V= A_ARGS__
#define MACRO_COMBIN_1(prefix_, center_, postfix_, ...)= prefix_ ## center_ ## postfix_(__VA_ARGS__)
#define MACRO_COMBI= N_2(...) MACRO_COMBIN_1(__VA_ARGS__)
#define MACRO_COMBIN_3(...)= MACRO_COMBIN_2(__VA_ARGS__)

#define list_make(..= .) MACRO_= COMBIN_3(list_make, MACRO_ARGS VA_ARGS_NARGS(__VA_ARGS__), /*empty*/, __VA= _ARGS__)
#define list_make_int(...) MACRO_COMBIN_3(list_make, MACRO_ARGS V= A_ARGS_NARGS(__VA_ARGS__), _int, __VA_ARGS__)
#define list_make_= oid(...) M= ACRO_COMBIN_3(list_make, MACRO_ARGS VA_ARGS_NARGS(__VA_ARGS__), _oid, __VA= _ARGS__)
=0A

=0A
bucoo@sohu.c= om
=0A
 
=
From: Tom Lane
Date: 2019-02-24 10:24<= /div>
Subject: POC: converting Lis= ts into arrays
For quite some years now there's= been dissatisfaction with our List
=0A
data structure implementa= tion.  Because it separately palloc's each
=0A
list cell, it= chews up lots of memory, and it's none too cache-friendly
=0A
be= cause the cells aren't necessarily adjacent.  Moreover, our typical=0A
usage is to just build a list by repeated lappend's and never = modify it,
=0A
so that the flexibility of having separately inser= table/removable list
=0A
cells is usually wasted.
=0A
&n= bsp;
=0A
Every time this has come up, I've opined that the right = fix is to jack
=0A
up the List API and drive a new implementation= underneath, as we did
=0A
once before (cf commit d0b4399d81).&nb= sp; I thought maybe it was about time
=0A
to provide some evidenc= e for that position, so attached is a POC patch
=0A
that changes = Lists into expansible arrays, while preserving most of
=0A
their = existing API.
=0A
 
=0A
The big-picture performance= change is that this makes list_nth()
=0A
a cheap O(1) operation,= while lappend() is still pretty cheap;
=0A
on the downside, lcon= s() becomes O(N), as does insertion or deletion
=0A
in the middle= of a list.  But we don't use lcons() very much
=0A
(and may= be a lot of the existing usages aren't really necessary?),
=0A
wh= ile insertion/deletion in long lists is a vanishingly infrequent
=0A<= div>operation.  Meanwhile, making list_nth() cheap is a *huge* win.=0A
 
=0A
The most critical thing that we lose by do= ing this is that when a
=0A
List is modified, all of its cells ma= y need to move, which breaks
=0A
a lot of code that assumes it ca= n insert or delete a cell while
=0A
hanging onto a pointer to a n= earby cell.  In almost every case,
=0A
this takes the form o= f doing list insertions or deletions inside
=0A
a foreach() loop,= and the pointer that's invalidated is the loop's
=0A
current-cel= l pointer.  Fortunately, with list_nth() now being so cheap,
=0A=
we can replace these uses of foreach() with loops using an integer=0A
index variable and fetching the next list element directly with=
=0A
list_nth().  Most of these places were loops around lis= t_delete_cell
=0A
calls, which I replaced with a new function lis= t_delete_nth_cell
=0A
to go along with the emphasis on the intege= r index.
=0A
 
=0A
I don't claim to have found ever= y case where that could happen,
=0A
although I added debug suppor= t in list.c to force list contents
=0A
to move on every list modi= fication, and this patch does pass
=0A
check-world with that supp= ort turned on.  I fear that some such
=0A
bugs remain, thoug= h.
=0A
 
=0A
There is one big way in which I failed= to preserve the old API
=0A
syntactically: lnext() now requires = a pointer to the List as
=0A
well as the current ListCell, so tha= t it can figure out where
=0A
the end of the cell array is. = That requires touching something
=0A
like 150 places that otherw= ise wouldn't have had to be touched,
=0A
which is annoying, even = though most of those changes are trivial.
=0A
 
=0AI thought about avoiding that by requiring Lists to keep a "sentinel"=0A
value in the cell after the end of the active array, so that lne= xt()
=0A
could look for the sentinel to detect list end.  Ho= wever, that idea
=0A
doesn't really work, because if the list arr= ay has been moved, the
=0A
spot where the sentinel had been could= have been reallocated and
=0A
filled with something else.  = So this'd offer no defense against the
=0A
possibility of a stale= ListCell pointer, which is something that
=0A
we absolutely need= defenses for.  As the patch stands we can have
=0A
quite a = strong defense, because we can check whether the presented
=0A
Li= stCell pointer actually points into the list's current data array.
= =0A
 
=0A
Another annoying consequence of lnext() needin= g a List pointer is that
=0A
the List arguments of foreach() and = related macros are now evaluated
=0A
each time through the loop.&= nbsp; I could only find half a dozen places
=0A
where that was ac= tually unsafe (all fixed in the draft patch), but
=0A
it's still = bothersome.  I experimented with ways to avoid that, but
=0Athe only way I could get it to work was to define foreach like this:=0A
 
=0A
#define foreach(cell, l)   &nb= sp;    for (const List *cell##__foreach =3D foreach_setup(l= , &cell);          cell != =3D NULL; cell =3D lnext(cell##__foreach, cell))
=0A
 
= =0A
static inline const List *
=0A
foreach_setup(const List *= l, ListCell **cell)
=0A
{
=0A
    *cell = =3D list_head(l);
=0A
    return l;
=0A
}=
=0A
 
=0A
That works, but there are two problems.&= nbsp; The lesser one is that a
=0A
not-very-bright compiler might= think that the "cell" variable has to
=0A
be forced into memory,= because its address is taken.  The bigger one is
=0A
that t= his coding forces the "cell" variable to be exactly "ListCell *";
=0A=
you can't add const or volatile qualifiers to it without getting=0A
compiler warnings.  There are actually more places that'd be= affected
=0A
by that than by the need to avoid multiple evaluati= ons.  I don't think
=0A
the const markings would be a big de= al to lose, and the two places in
=0A
do_autovacuum that need "vo= latile" (because of a nearby PG_TRY) could
=0A
be rewritten to no= t use foreach.  So I'm tempted to do that, but it's
=0A
not = very pretty.  Maybe somebody can think of a better solution?
=0A=
 
=0A
There's a lot of potential follow-on work that I'= ve not touched yet:
=0A
 
=0A
1. This still involve= s at least two palloc's for every nonempty List,
=0A
because I ke= pt the header and the data array separate.  Perhaps it's
=0Aworth allocating those in one palloc.  However, right now there's an=
=0A
assumption that the header of a nonempty List doesn't move w= hen you
=0A
change its contents; that's embedded in the API of th= e lappend_cell
=0A
functions, and more than likely there's code t= hat depends on that
=0A
silently because it doesn't bother to sto= re the results of other
=0A
List functions back into the appropri= ate pointer.  So if we do that
=0A
at all I think it'd be be= tter tackled in a separate patch; and I'm
=0A
not really convince= d it's worth the trouble and extra risk of bugs.
=0A
 
= =0A
2. list_qsort() is now absolutely stupidly defined.  It shoul= d just
=0A
qsort the list's data array in-place.  But that r= equires an API
=0A
break for the caller-supplied comparator, sinc= e there'd be one less
=0A
level of indirection.  I think we = should change this, but again it'd
=0A
be better done as an indep= endent patch to make it more visible in the
=0A
git history.=0A
 
=0A
3. There are a number of places where we've b= uilt flat arrays
=0A
paralleling Lists, such as the planner's sim= ple_rte_array.  That's
=0A
pointless now and could be undone= , buying some code simplicity.
=0A
Various other micro-optimizati= ons could doubtless be done too;
=0A
I've not looked hard.
= =0A
 
=0A
I haven't attempted any performance measuremen= ts on this, but at
=0A
least in principle it should speed things = up a bit, especially
=0A
for complex test cases involving longer = Lists.  I don't have any
=0A
very suitable test cases at han= d, anyway.
=0A
 
=0A
I think this is too late for v= 12, both because of the size of the
=0A
patch and because of the = likelihood that it introduces a few bugs.
=0A
I'd like to conside= r pushing it early in the v13 cycle, though.
=0A
 
=0A<= div> regards, tom lane
=0A
 
=0A
= =0A ------=_001_NextPart031157638012_=------