Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD81G-00G8Ul-1a for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Nov 2024 20:06:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tD81E-007FSI-6g for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Nov 2024 20:06:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD81D-007FS9-LM for pgsql-hackers@lists.postgresql.org; Mon, 18 Nov 2024 20:06:44 +0000 Received: from mx0a-000e5c18.pphosted.com ([205.220.169.92]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD819-002crb-08 for pgsql-hackers@lists.postgresql.org; Mon, 18 Nov 2024 20:06:42 +0000 Received: from pps.filterd (m0285253.ppops.net [127.0.0.1]) by mx0a-000e5c18.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4AIJt7U3030721; Mon, 18 Nov 2024 20:06:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mdlive.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pod0510241234; bh=zmcFPzZzNUcFLqZvVnNR qUE+69aJqJ+p1glCmTW3d6o=; b=bYpa22SFQC9TwScV2gHcxfeKEyC4kMP4+DV7 tcVU9YL8gIYa4ipfWxvq0x9wGqU0FceybpQT6u0LAzQGo3fR3URRfs+nH2TXSSb7 8RdpUGiw0CmYjUVmsdq6vISrcl5u2QxokoywEWto74H+53F2xS1U7QDPXv+xqO6o Fl5ch/fD0Ez6z198KS8lkqmSc4611cEKVvQZWxY92Bj++aM7op3Q9OIt4NBt0Pn/ 8h/BmMy0sYv3EOsuTYrVKZEgmQ0dzub4oyzS3vQiMylJoL+ytadGTJMJyTr5MEJt qejHf4w3H6tW0YVFKiQUnPVsMLEZNH71JvkyOxj90U/LV8P9oA== Received: from eiaappxp0012.gid.prd.globalcore.com (lyncav03.cigna.com [170.48.19.151] (may be forged)) by mx0a-000e5c18.pphosted.com (PPS) with ESMTPS id 4302qes57s-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2024 20:06:29 +0000 (GMT) Received: from cvlappxp20769.internal.cigna.com (HELO CIWX9MAP0070.internal.cigna.com) ([10.31.88.210]) by EIAAPPXP0012.gid.prd.globalcore.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2024 20:06:27 +0000 Received: from CIWX9MAP0067.internal.cigna.com (10.25.171.135) by CIWX9MAP0070.internal.cigna.com (10.25.171.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 18 Nov 2024 15:06:27 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (10.120.223.5) by CIWX9MAP0067.internal.cigna.com (10.25.171.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11 via Frontend Transport; Mon, 18 Nov 2024 15:06:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iK+YITplKCEsGmgV8JG4i6cbhGl9EZnRwoafMMYlmgvO0/WP+9j2dcVK1yaiwKSf3dQuvrY7mhFm+6UZmKM6+gNyIZCqUnnqq23ZvNOcfMPZpzXGzZDErjd2UShD1CM4rQM00wi5hlABbcXDnef3tIooIB+6G/oCKIo7s1iV9N4VjLFfaGmcjKazrKfhV+vrGer3Diu+m110BLb0AU+wicBS3KXgT+vi4X2ybkgvrPqTLlJpFMektkqv0Gt1YLCteb6hMl15/KfTh20I/Jvsn+c8FBhS9/BUwBi5OnMaj7r2ECI6mDS4ae7cEdPTu4aXo4rMr8jblPzICUewr0kFOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WMojsFIToIjfhBjheXMhCxH2cllEFJHkSRXFaGEFbTA=; b=hpxQF59deMBWs69F+Nm9QY0Ix1yIM5gTuDC9SAtnH2YP9XQSKpn6zuiPh2LMC5VLTTC3Z15rpmTEf8R/lU8/JJ4onhW2vNS+ckCOpVn5gpHITik9gzubdab0pfYI54urcnJ3D0oZ3SLLarouRfz3utcMPJyLKscPlOlQl/v7y9IEkHfFVhg0WAdIZEVzJqtRMI/Ci9/uTrHPGBpDELSGkDHmY0N5Ik1VbmvL4vgCpj7hpRzSBPNTNECgTKygQlIA156WmOGMvJWyJT8evkkuoP2kJjRCdyU8x/0RSJ2qKMy1ZfQKNVkac12atN3F3j6sQSLAsEVOdLoJppAG71FDHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mdlive.com; dmarc=pass action=none header.from=mdlive.com; dkim=pass header.d=mdlive.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cignatlp.onmicrosoft.com; s=selector2-cignatlp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WMojsFIToIjfhBjheXMhCxH2cllEFJHkSRXFaGEFbTA=; b=fd3A1QssP1ffL3fv6u1kJVxW9etGGnSo8Qd4XLq8Y8C5+jZTSmDF1X3THQtOWlPmn9O7FxQv6iUZkgOw6AI8jOuh35Uf7F5lnux1Emw4qNELRkm9MzyAZFYzR/ydfk5dv18w2zxfbCWGGJKZmlptwIXsPf+IKXpW2fyohJ+YHI4= Received: from DM4PR12MB5040.namprd12.prod.outlook.com (2603:10b6:5:38b::19) by SN7PR12MB7834.namprd12.prod.outlook.com (2603:10b6:806:34d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8158.23; Mon, 18 Nov 2024 20:06:25 +0000 Received: from DM4PR12MB5040.namprd12.prod.outlook.com ([fe80::a3dc:7ea1:9cc7:ce0f]) by DM4PR12MB5040.namprd12.prod.outlook.com ([fe80::a3dc:7ea1:9cc7:ce0f%6]) with mapi id 15.20.8158.023; Mon, 18 Nov 2024 20:06:24 +0000 From: "Wetmore, Matthew (CTR)" To: Bruce Momjian , Corey Huinker CC: Jeff Davis , jian he , Matthias van de Meent , Tom Lane , Nathan Bossart , "Magnus Hagander" , Stephen Frost , "Ashutosh Bapat" , Peter Smith , PostgreSQL Hackers , "alvherre@alvh.no-ip.org" Subject: Re: Statistics Import and Export Thread-Topic: Statistics Import and Export Thread-Index: AQHa9Z4WSTnJgKALN0+ob2+wCWisBrI6ePQAgA8PioCAA7J0AIAOmo6AgDyW/QCACOByAIAHGvMAgAXEBYCAD849AP//fzMA Date: Mon, 18 Nov 2024 20:06:24 +0000 Message-ID: References: <11bb2c7403d4a7421fe8b09df6737aa83976266e.camel@j-davis.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB5040:EE_|SN7PR12MB7834:EE_ x-ms-office365-filtering-correlation-id: dd7d421d-2535-456e-f0b8-08dd080c7ac1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|8096899003|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?M1JjWnd2SnRDNkcyMFFheXFnQmZMQWdhVElCK3NEQ1RxZE5iOVh2OVRTS2FX?= =?utf-8?B?YlRtOENGUUNiOGZ0M1lacUQreGdUZ3dzM045WDA3ZmVCVmpSaCtHZWFoNlZ2?= =?utf-8?B?R3ZFZ1krdkkyQndWcHczOWpSSEJUU3pWV3gyRGNLbXdLV1VYRGxtdmVyVHBC?= =?utf-8?B?T3ZlTFVKUG5hbzJ0RGRlT0wvZGEwQVdXQjZZN09WY0hJM0prS2FBNzQrYzlw?= =?utf-8?B?R0xWSlJhbUtJQXgvbmlzWlhOdy9SQmY3MDJOUnBsQmVnMFFpUnNrTWdJdDEw?= =?utf-8?B?bTVvRWJ4WS9BVFlwbjJ2Sy9rdExKK3FPRDJxU0t0M0crb1ZiSktEazl1Wklq?= =?utf-8?B?alhtSGVBbU1IZnpkcTdSMmlqY3JjTTNCK2FtSk9mV244T2pNanl0bEtta0Jj?= =?utf-8?B?V3FDU0dxZTdaVktZY1ZQUTRmUjZiRUt2S0sxYmUveUV0VkJqMXZHUjl3K3Vq?= =?utf-8?B?Zi84dWxHdnA4NE1qUWs4UXY0TFFhbkh6QlJvMnc3NTI0TnVBK2NGaTAwaUJC?= =?utf-8?B?R3RHRXRUcEh1emlJdUJCWG13cE1SMU5iR0ZvVXU1Z1FsRkR1YVAvZTcyUG96?= =?utf-8?B?Y2hsSHlLMkhRTHR6UHNObnp2ZzR1aFdKc1VYUm1OekNpcjd1UlhxaDVwV0wy?= =?utf-8?B?a0tNU3J6VTQ2WGMwVE5hZk9GTVcraCtzMllsWDhGaEljalBURy9LQWo1OEx0?= =?utf-8?B?SW5KZkJFMmZLZk5hMXUwcnNiQ0lMQ2dtaG9qSWx0VExZOTZWYUR6OGN1S0M5?= =?utf-8?B?a0dUbmZFSGZpb2NBME1WNmlpam1NdWttcEhpNnlRQkFodHZyY0pGL3RxVWI0?= =?utf-8?B?cW5nRHFubEEwUk1ya1VUOHF3SFhkRHdxa0doOUljN1FNVGpKRFZyam5SOWdo?= =?utf-8?B?VmVvSDZBN0VTN25GU0VhNG9meTA5RzRJTk1HS2w1dnpGTlVmZUZXdHIzckY0?= =?utf-8?B?elMxN2pidlRFTm92SzBCQ0R2eFkxMlJKR1NDUVRUc3RkTjhEa1ZFRnNpemlP?= =?utf-8?B?TXF0S0tsVW5WSFRnNC8zdmFUbzdZZHkyL25IMERNUENvdHBXY0FTbFBaOEpn?= =?utf-8?B?eWZRSjdHZlJSbnNUNzFmaE03RStuYk9qNUZDR2J2MmpDZ3F2aVFBaW1hVFJU?= =?utf-8?B?MHFFUEFKSmhvUVNEa0IvaGRjcmpmQWkzQ1BpcjBOcEx4OWNYeFNyU0RXVUVZ?= =?utf-8?B?VEVIempYdFpQK0lJeStMcGJSdm55dXNSNVVYb1M0ZDAwSFQ5ZTVFZnpxamQ3?= =?utf-8?B?MFREam9KSXpkaEROU0VUdHdUK21YTW8zUGp6eDlPank5KzB4dWRqZHd2K1NT?= =?utf-8?B?aW50eFFwZzlHZUVJYzh0UHRLQ1BZbzFHNmVaUXdrVUpaNGdrc2w4K3ZyMTJB?= =?utf-8?B?ejdDY0drNzZMWGZjNTI4a0JoclU5SnFpQ0dGemtvNTQ1RW1VTjExVjlvd3Fn?= =?utf-8?B?YkNxRjVVTEIrRGZmVHp4ei9KMWpzSkNsSmN1OTM1NVh1a0MwSDludkNmbWRC?= =?utf-8?B?bld6bEVwR1NRNis5WldkYVRGa1RzWXRnRnRRWDlLcEZ1VFFrcEdyRzB2dU9H?= =?utf-8?B?SlhMSnhjRzJadStEUFVCY2VwRkRQVzdqUWFRUHVDQlpRVi9aVkhqUjZqS0Ez?= =?utf-8?B?ODRFd3RLWHJJV3drc282bTZFUVE3VmwyVlVMTTVVYzdmTWxPSmM2VU5QMnMx?= =?utf-8?B?bE9mcFVxdkl3WHFpR2hMTUo5L0UrYmh5c08rYmxRaWZybHJINjA3ZnNZMU9T?= =?utf-8?Q?lMCa9NlOE8Uz0GpIqseKTR/Noj2X5PY25HDfdZT?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5040.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(8096899003)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RTVqaDRyR0V2akVBSTludTNjSG5Ib050cngvb1hXbkRlUGVJdEhQc2ZOR2ZB?= =?utf-8?B?VzB2TEJlcG16c0prTUtYR2JEOTNMNWdXVjEyKy91TXBNdlJncEc5Yzk0azRY?= =?utf-8?B?Q2d3UjMwNDcxOTdEcWpYc3JtVnFlY080KzhGcjBZQVFZc0ppTDRZRUdJVktP?= =?utf-8?B?Y3ZVNG52TDF6SDVwU3FmMUJZOGRyTUgvYkE0QmFpZE5LZEYyUXdLZERuSHhj?= =?utf-8?B?OE1qSXlyVzNNZXRPQStzVFBuZ3N4Zzg3UlBXamlkS2lleUcvZTFFNU00eGpZ?= =?utf-8?B?aDNuVmM2OUkvVGVEb2hpWXR0Ui9jbURDWW9jYlBud2lwTmtjS1oyMko4V2ZV?= =?utf-8?B?TlRlSkJSallOOHFsZy9UZXR3OVpxaU5iNW9zOXBmRHVCRUZSODRuaVA1aUZR?= =?utf-8?B?ZnBCbVUrTU4wYkpqQ0xMZXIzRWZwUFdoZlg5alB6dldXTnZzeHNpLzJMdnpR?= =?utf-8?B?TjFBTWhkbzNER0kxZWRzSEhra1JaZE5HRWhUYzY4eTdzMGNMU0sxdytwWmp3?= =?utf-8?B?U3lHWGZTLzFqdHM3V1hnZW5YdzlQMm1ab09yZTJVMkN3aGc5NEtTM2IyZmt4?= =?utf-8?B?Si81NjJ2WHlrRnd0NnVlb2UrbmhMcEpHODdnOGUzQVh0ZXgzUkl5Wmg3UmhC?= =?utf-8?B?RnpkNFR0U2czcHIrcm96N2FvK2xRUHY4RGh6cFB5QlN2c1hvZVh1amZVMC92?= =?utf-8?B?bVB4UHczL21naEVPMFhyV2Y3OGsyNEE3b2F4ZkdtSzFBKzNwaHpCMzZIWXJa?= =?utf-8?B?QlplbUZLYkdBZ1QyLzd2NEo4NkhHUmxZSmhVbFBpNnFBcC9WVC85a1lHS0pF?= =?utf-8?B?UDJEZUllK2M2OVFDQnVXQ3JVSXl6QklWUmtjNzhoeFhaYXQ4R0J0em1vR3JX?= =?utf-8?B?c1VsZ1dnN1dNWHFvWnIxNXRtcWdLZk9hNzZxY2w3VXpNOEppcHlMSk04K1BR?= =?utf-8?B?cjhHUy8vNWVGL2F5TXFjMml1RmY0ZGdsSWc1bmtha2laQVMzYVdobzlRbXB1?= =?utf-8?B?cEdtNURUOHlPS3c5RExNRG1mTE1QSnErMjFTbGM2Z1lSOEVaUTJnYmNIUHha?= =?utf-8?B?MGt3elIycWc5UENYOEdZRTh3MXpZQVhRU0g2KzRsdTFQRkFIQ2VmNHM5K2lG?= =?utf-8?B?NXoyT09rall4aUdMSVhXT1JoeXUwcGFMRmFTbHNJZm5hbXJBTG9ubmUwQUJL?= =?utf-8?B?TFNDS1VjU3NSa05ML3pEbys1QjVOY0l5YXVoK3ZnaW51WjFIdGozcU4zQXV5?= =?utf-8?B?YjJhWmkxUVJ4eVozYmNrNDZLUzJyUnYxZDVuQ2JyOURvT2hGdXdkbjhhNXJ3?= =?utf-8?B?S2orSDE1cDhPbVNwWG83R0hPdCtSUlhiVWU1dklINHg4SFl3dUoxZ3ZNVXBn?= =?utf-8?B?ZkRncmU5OVpoUHF4aWVIbHJ6N2pMNG9tVE0yY3dwVkNrUnNGMHg5Qm5keXRZ?= =?utf-8?B?UytoY1haR0dxS1RFQWFPVHN4cS9jQS9Tb3JVWmFpYUdaZXg1SXRMRVRZWVkr?= =?utf-8?B?cktzZGtod3RnVk5yUjBtUi9YNThnSVR6NytYZHA2Q083T1lmU00yemloZmgv?= =?utf-8?B?Y2ZtN2dMSVJNTVo3T04wQUw4SGIraXR2SUlJUkdYQmo0Mkl2MnFFTjNaSXZp?= =?utf-8?B?Rm0rTVV3cFBQdXNDQm14bW1UNjhJcVJpdVJ1MnJFbUhpb0poLzF4U2NBY2FV?= =?utf-8?B?Q3JEV21lRDRTVUVZbzZKN1NWUFQvS0Z5NmxuUWplZ2F1SFkvTzhrd20zck42?= =?utf-8?B?S0pDVWRQZ0lQeitaRWxqNVNvM1BQY2wwU2wrV0Y1THdHK1hwN251UFhGc3Ry?= =?utf-8?B?K0RoMFl2R3kvM09KZkhia243ZENqSnZJRktpdGE5TXhVR0JTekFPLzNHVno0?= =?utf-8?B?U0hmQlpBMER6dW82dnRJYjNueWcvMGx0WGZVTUlOaUNTclZnSG1VeHQxK3VC?= =?utf-8?B?LzlHRlpKK1BaKzNBREdoVU5nZ3BMelpvRExMTGcvRUlieG1oR2pqazM2eUw4?= =?utf-8?B?c1ZET3pncHZnOU4xYkpTZDVuTlhGMGdtblcvV0FaTzRjWFJJdEUrdVViZFJE?= =?utf-8?B?TGVrVnNaRHJ6c0pPbExBOC9oSE9JQmIxWi9wb3k1UTczczh2RzNLSmxtQlhv?= =?utf-8?B?Tk9DeCthK0tEcW5ic3ZCME5QM1d2eWc3YjhEejlSSVNZMW1VL3BOS21jZkJv?= =?utf-8?B?SlE9PQ==?= Content-Type: multipart/related; boundary="_004_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5040.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd7d421d-2535-456e-f0b8-08dd080c7ac1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2024 20:06:24.8499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 791b26cb-3fdf-47c3-b85d-bd9f037e3e7f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 76lDX9LP37dFbXWvenzAAa25dbjwz7f69qIebOM0U8k9goPoQTEfYzZKnUP0JEjR4iNpDppIRJvzA8QESwgSpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7834 X-ProofPoint-Routing: 000e5c18 X-CFilter-Loop: Reflected X-Proofpoint-GUID: F63PPJjjsSy_5WfYz-JSibKLy70jumKX X-Proofpoint-ORIG-GUID: F63PPJjjsSy_5WfYz-JSibKLy70jumKX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 mlxscore=0 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2409260000 definitions=main-2411180164 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_004_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_ Content-Type: multipart/alternative; boundary="_000_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_" --_000_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry to chime in with a dumb question: How would/could this effect tables that have the vacuum and analyze scale_f= actors different from the rest of db via the ALTE RTABLE statement? (I do this a lot) ALTER TABLE your_schema.your_table SET (autovacuum_enabled,autovacuum_analy= ze_scale_factor,autovacuum_vacuum_scale_factor); Just wanted to mention Thanks Bruce, /matt -- [MDLIVE] Matt Wetmore Data Engineer m. +1-415-416-9738 From: Bruce Momjian Date: Monday, November 18, 2024 at 11:48=E2=80=AFAM To: Corey Huinker Cc: Jeff Davis , jian he , = Matthias van de Meent , Tom Lane , Nathan Bossart , Magnus Hagander , Stephen Frost , Ashutosh Bapat , Peter Smith , PostgreSQL Hac= kers , "alvherre@alvh.no-ip.org" Subject: Re: Statistics Import and Export On Fri, Nov 8, 2024 at 01:=E2=80=8A25:=E2=80=8A21PM -0500, Corey Huinker wr= ote: > WHAT IS NOT DONE - EXTENDED STATISTICS > > It is a general consensus= in the community that "nobody uses extended > statistics", though I've had= difficulty getting actual On Fri, Nov 8, 2024 at 01:25:21PM -0500, Corey Huinker wrote: > WHAT IS NOT DONE - EXTENDED STATISTICS > > It is a general consensus in the community that "nobody uses extended > statistics", though I've had difficulty getting actual figures to bac= k this > up, even from my own employer. Surveying several vendors at PgConf.EU= , the > highest estimate was that at most 1% of their customers used extended > statistics, though more probably should. This reinforces my belief th= at a > feature that would eliminate a major pain point in upgrades for 99% of > customers shouldn't be held back by the fact that the other 1% only h= ave a > reduced hassle. > > However, having relation and attribute statistics carry over on major > version upgrades presents a slight problem: running vacuumdb > --analyze-in-stages after such an upgrade is completely unnecessary f= or > those without extended statistics, and would actually result in _wors= e_ > statistics for the database until the last stage is complete. Granted, > we've had great difficulty getting users to know that vacuumdb is a t= hing > that should be run, but word has slowly spread through our own > documentation and those "This one simple trick will make your postgre= s go > fast post-upgrade" blog posts. Those posts will continue to lurk in s= earch > results long after this feature goes into release, and it would be a = rude > surprise to users to find out that the extra work they put in to learn > about a feature that helped their upgrade in 17 was suddenly detrimen= tal > (albeit temporarily) in 18. We should never punish people for only be= ing a > little-bit current in their knowledge. Moreover, this surprise would > persist even after we add extended statistics import function > functionality. > > I presented this problem to several people at PgConf.EU, and the cons= ensus > least-bad solution was that vacuumdb should filter out tables that ar= e not > missing any statistics when using options --analyze, --analyze-only, = and > --analyze-in-stages, with an additional flag for now called --force-a= nalyze > to restore the un-filtered functionality. This gives the outcome tree: > > 1. Users who do not have extended statistics and do not use (or not e= ven > know about) vacuumdb will be blissfully unaware, and will get better > post-upgrade performance. > 2. Users who do not have extended statistics but use vacuumdb > --analyze-in-stages will be pleasantly surprised that the vacuumdb ru= n is > almost a no-op, and completes quickly. Those who are surprised by thi= s and > re-run vacuumdb --analyze-in-stages will get another no-op. > 3. Users who have extended statistics and use vacuumdb --analyze-in-s= tages > will get a quicker vacuumdb run, as only the tables with extended sta= ts > will pass the filter. Subsequent re-runs of vacuumdb --analyze-in-sta= ges > would be the no-op. > 4. Users who have extended statistics and don't use vacuumdb will sti= ll get > better performance than they would have without any stats imported. > > In case anyone is curious, I'm defining "missing stats" as a table/ma= tview > with any of the following: > > 1. A table with an attribute that lacks a corresponding pg_statistic = row. > 2. A table with an index with an expression attribute that lacks a > corresponding pg_statistic row (non-expression attributes just borrow= the > pg_statistic row from the table's attribute). > 3. A table with at least one extended statistic that does not have a > corresponding pg_statistic_ext_data row. > > Note that none of these criteria are concerned with the substance of = the > statistics (ex. pg_statistic row should have mcv stats but does not), > merely their row-existence. > > Some rejected alternative solutions were: > > 1. Adding a new option --analyze-missing-stats. While simple, few peo= ple > would learn about it, knowledge of it would be drowned out by the > aforementioned sea of existing blog posts. > 2. Adding --analyze-missing-stats and making --analyze-in-stages fail= with > an error message educating the user about --analyze-missing-stats. Us= ers > might not see the error, existing tooling wouldn't be able to act on = the > error, and there are legitimate non-upgrade uses of --analyze-in-stag= es. > > MAIN CONCERN GOING FORWARD > > This change to vacuumdb will require some reworking of the > vacuum_one_database() function so that the list of tables analyzed is > preserved across the stages, as subsequent stages runs won't be able = to > detect which tables were previously missing stats. You seem to be optimizing for people using pg_upgrade, and for people upgrading to PG 18, without adequately considering people using vacuumdb in non-pg_upgrade situations, and people using PG 19+. Let me explain. First, I see little concern here for how people who use --analyze and --analyze-only independent of pg_upgrade will be affected by this. While I recommend people decrease vacuum and analyze threshold during non-peak periods: https://urldefense.com/v3/__https://momjian.us/main/blogs/pg= blog/2017.html*January_3_2017__;Iw!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU= 3lWjh76cjhyOBvdbX0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrCfXFTNfw$ some people might just regenerate all statistics during non-peak periods using these options. You can perhaps argue that --analyze-in-stages would only be used by pg_upgrade so maybe that can be adjusted more easily. Second, the API for what --analyze and --analyze-only do will be very confusing for people running, e.g., PG 20, because the average user reading the option name will not guess it only adds missing statistics. I think you need to rethink your approach and just accept that a mention of the new preserving statistic behavior of pg_upgrade, and the new vacuumdb API required, will be sufficient. In summary, I think you need a new --compute-missing-statistics-only that can be combined with --analyze, --analyze-only, and --analyze-in-stages to compute only missing statistics, and document it in the PG 18 release notes. Frankly, we have a similar problem with partitioned tables: https://urldefense.com/v3/__https://www.postgresql.org/docs/= current/sql-analyze.html__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76= cjhyOBvdbX0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrAcfiLyFQ$ For partitioned tables, ANALYZE gathers statistics by sampli= ng rows from all partitions; in addition, it will recurse into each partition and update its statistics. Each leaf partition is analyzed only once, even with multi-level partitioning. No statistics are collected for only the parent table (without = data from its partitions), because with partitioning it's guarant= eed to be empty. --> The autovacuum daemon does not process partitioned tables, nor does it process inheritance parents if only the children are= ever modified. It is usually necessary to periodically run a manu= al ANALYZE to keep the statistics of the table hierarchy up to = date. Now, you can say partitioned table statistics are not as important as extended statistics, but that fact remains that we have these two odd cases where special work must be done to generate statistics. -- Bruce Momjian https://urldefense.com/v3/__http= s://momjian.us__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhyOBvdbX= 0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrCf9HVZng$ EDB https://urldefense.com/v3/__http= s://enterprisedb.com__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhy= OBvdbX0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrBvicktqQ$ When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?" --_000_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-ID: <70D35C91EFC22142A2332DCE9ADCD10A@namprd12.prod.outlook.com>

Sorry to chime in w= ith a dumb question:

 

How would/could thi= s effect tables that have the vacuum and analyze scale_factors different fr= om the rest of db via the ALTE RTABLE statement?

 

(I do this a lot)

 

ALTER TABLE your_sc= hema.your_table SET (autovacuum_enabled,autovacuum_analyze_scale_factor,aut= ovacuum_vacuum_scale_factor);

 

Just wanted to ment= ion

 

Thanks Bruce,<= /o:p>

 

/matt

 

-- 


3D"MDLIVE"

Matt Wetmore

Data Engineer

m. +1-415-416-9738

 

 

From: Bruce Momjian <bruce@momjian.us>
Date: Monday, November 18, 2024 at 11:48=E2=80=AFAM
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, jian he <jian.universal= ity@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com&g= t;, Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathandbossart@g= mail.com>, Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.co= m>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pg= sql-hackers@lists.postgresql.org>, "alvherre@alvh.no-ip.org" &= lt;alvherre@alvh.no-ip.org>
Subject: Re: Statistics Import and Export

 

On Fri, Nov 8, 2024 at 01:=E2= =80=8A25:=E2=80=8A21PM -0500, Corey Huinker wrote: > WHAT IS NOT DONE - EXTENDED STATISTICS &g= t; > It is a general consensus in the community that "nobody uses e= xtended > statistics", though I've had difficulty getting actual

On Fri, Nov  8, 2024 at 01:25:21PM =
-0500, Corey Huinker wrote:
>     WHAT IS NOT DONE - EXTENDED STATISTICS
> 
>     It is a general consensus in the community=
 that "nobody uses extended
>     statistics", though I've had difficul=
ty getting actual figures to back this
>     up, even from my own employer. Surveying s=
everal vendors at PgConf.EU, the
>     highest estimate was that at most 1% of th=
eir customers used extended
>     statistics, though more probably should. T=
his reinforces my belief that a
>     feature that would eliminate a major pain =
point in upgrades for 99% of
>     customers shouldn't be held back by the fa=
ct that the other 1% only have a
>     reduced hassle.
> 
>     However, having relation and attribute sta=
tistics carry over on major
>     version upgrades presents a slight problem=
: running vacuumdb
>     --analyze-in-stages after such an upgrade =
is completely unnecessary for
>     those without extended statistics, and wou=
ld actually result in _worse_
>     statistics for the database until the last=
 stage is complete. Granted,
>     we've had great difficulty getting users t=
o know that vacuumdb is a thing
>     that should be run, but word has slowly sp=
read through our own
>     documentation and those "This one sim=
ple trick will make your postgres go
>     fast post-upgrade" blog posts. Those =
posts will continue to lurk in search
>     results long after this feature goes into =
release, and it would be a rude
>     surprise to users to find out that the ext=
ra work they put in to learn
>     about a feature that helped their upgrade =
in 17 was suddenly detrimental
>     (albeit temporarily) in 18. We should neve=
r punish people for only being a
>     little-bit current in their knowledge. Mor=
eover, this surprise would
>     persist even after we add extended statist=
ics import function
>     functionality.
> 
>     I presented this problem to several people=
 at PgConf.EU, and the consensus
>     least-bad solution was that vacuumdb shoul=
d filter out tables that are not
>     missing any statistics when using options =
--analyze, --analyze-only, and
>     --analyze-in-stages, with an additional fl=
ag for now called --force-analyze
>     to restore the un-filtered functionality. =
This gives the outcome tree:
> 
>     1. Users who do not have extended statisti=
cs and do not use (or not even
>     know about) vacuumdb will be blissfully un=
aware, and will get better
>     post-upgrade performance.
>     2. Users who do not have extended statisti=
cs but use vacuumdb
>     --analyze-in-stages will be pleasantly sur=
prised that the vacuumdb run is
>     almost a no-op, and completes quickly. Tho=
se who are surprised by this and
>     re-run vacuumdb --analyze-in-stages will g=
et another no-op.
>     3. Users who have extended statistics and =
use vacuumdb --analyze-in-stages
>     will get a quicker vacuumdb run, as only t=
he tables with extended stats
>     will pass the filter. Subsequent re-runs o=
f vacuumdb --analyze-in-stages
>     would be the no-op.
>     4. Users who have extended statistics and =
don't use vacuumdb will still get
>     better performance than they would have wi=
thout any stats imported.
> 
>     In case anyone is curious, I'm defining &q=
uot;missing stats" as a table/matview
>     with any of the following:
> 
>     1. A table with an attribute that lacks a =
corresponding pg_statistic row.
>     2. A table with an index with an expressio=
n attribute that lacks a
>     corresponding pg_statistic row (non-expres=
sion attributes just borrow the
>     pg_statistic row from the table's attribut=
e).
>     3. A table with at least one extended stat=
istic that does not have a
>     corresponding pg_statistic_ext_data r=
ow.
> 
>     Note that none of these criteria are conce=
rned with the substance of the
>     statistics (ex. pg_statistic row should ha=
ve mcv stats but does not),
>     merely their row-existence. 
> 
>     Some rejected alternative solutions were:<=
o:p>
> 
>     1. Adding a new option --analyze-missing-s=
tats. While simple, few people
>     would learn about it, knowledge of it woul=
d be drowned out by the
>     aforementioned sea of existing blog posts.=

>     2. Adding --analyze-missing-stats and maki=
ng --analyze-in-stages fail with
>     an error message educating the user about =
--analyze-missing-stats. Users
>     might not see the error, existing tooling =
wouldn't be able to act on the
>     error, and there are legitimate non-upgrad=
e uses of --analyze-in-stages.
> 
>     MAIN CONCERN GOING FORWARD
> 
>     This change to vacuumdb will require some =
reworking of the
>     vacuum_one_database() function so that the=
 list of tables analyzed is
>     preserved across the stages, as subsequent=
 stages runs won't be able to
>     detect which tables were previously missin=
g stats.
 
You seem to be optimizing for people using pg_upgrade, and for people
upgrading to PG 18, without adequately considering people using vacuumd=
b
in non-pg_upgrade situations, and people using PG 19+.  Let me exp=
lain.
 
First, I see little concern here for how people who use --analyze and
--analyze-only independent of pg_upgrade will be affected by this. 
While I recommend people decrease vacuum and analyze threshold during
non-peak periods:
 
            =
;   https://urldefense.com/v3/__https://momjian.us/main/blogs/pgblog/2017.html=
*January_3_2017__;Iw!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhyOBv=
dbX0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrCfXFTNfw$

 


some people might just regenerate all statistics during non-peak period=
s


using these options.  You can perhaps argue that --analyze-in-stag=
es


would only be used by pg_upgrade so maybe that can be adjusted more


easily.


 


Second, the API for what --analyze and --analyze-only do will be very


confusing for people running, e.g., PG 20, because the average user


reading the option name will not guess it only adds missing statistics.=



 


I think you need to rethink your approach and just accept that a mentio=
n


of the new preserving statistic behavior of pg_upgrade, and the new


vacuumdb API required, will be sufficient.  In summary, I think yo=
u need


a new --compute-missing-statistics-only that can be combined with<=
/o:p>


--analyze, --analyze-only, and --analyze-in-stages to compute only=



missing statistics, and document it in the PG 18 release notes.


 


Frankly, we have a similar problem with partitioned tables:<=
/span>


 


            =
;   https:=
//urldefense.com/v3/__https://www.postgresql.org/docs/current/sql-analyze.h=
tml__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhyOBvdbX0A7yWbineV7=
Ax1atOztVc1CUn_MTpqVGWkyGKDrAcfiLyFQ$


            =
;   


            =
;   For partitioned tables, ANALYZE gathers statistics by samplin=
g


            =
;   rows from all partitions; in addition, it will recurse into


            =
;   each partition and update its statistics. Each leaf partition=



            =
;   is analyzed only once, even with multi-level partitioning. No=



            =
;   statistics are collected for only the parent table (without d=
ata


            =
;   from its partitions), because with partitioning it's guarante=
ed


            =
;   to be empty.


 


-->          The autova=
cuum daemon does not process partitioned tables, nor


            =
;   does it process inheritance parents if only the children are =
ever


            =
;   modified. It is usually necessary to periodically run a manua=
l


            =
;   ANALYZE to keep the statistics of the table hierarchy up to d=
ate.


 


Now, you can say partitioned table statistics are not as important as


extended statistics, but that fact remains that we have these two odd


cases where special work must be done to generate statistics.


 


-- 


  Bruce Momjian  <bruce@momjian.us>  &nb=
sp;     https://urldefense.com/v3/__ht=
tps://momjian.us__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhyOBvd=
bX0A7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrCf9HVZng$

  EDB          &=
nbsp;           &nbs=
p;            &=
nbsp;  https://urldefense.com/v3/__https://ente=
rprisedb.com__;!!JtyhRs6NQr98nj80!5p5jBUgKYWVIwaCN-IBjzU3lWjh76cjhyOBvdbX0A=
7yWbineV7Ax1atOztVc1CUn_MTpqVGWkyGKDrBvicktqQ$


 


  When a patient asks the doctor, "Am I going to die?", =
he means 


  "Am I going to die soon?"


 


 
--_000_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_-- --_004_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3811; creation-date="Mon, 18 Nov 2024 20:06:24 GMT"; modification-date="Mon, 18 Nov 2024 20:06:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASwAAABeCAMAAACuPtk5AAABg1BMVEUAAADxZyPxZyN2eHvxZyPx ZyMjHyDxZyPxZyPxZyN2eHt2eHt2eHsjHyAjHyAjHyAjHyDxZyN2eHt2eHvxZyPxZyN2eHsjHyAj HyAjHyAjHyAjHyB2eHvxZyMjHyDxZyMjHyAjHyAjHyAjHyAjHyAjHyAjHyAjHyAjHyAjHyDxZyPx ZyMjHyAjHyDxZyMjHyAjHyAjHyDxZyMjHyAjHyB2eHsjHyAjHyAjHyAjHyAjHyB2eHsjHyB2eHsj HyAjHyAjHyAjHyB2eHsoJSZ2eHsjHyAjHyB2eHsjHyDxZyMjHyAjHyDxZyPxZyN2eHsjHyAjHyB2 eHvxZyN2eHvxZyMjHyB2eHt2eHvxZyN2eHt2eHvxZyPxZyN2eHvxZyPxZyPxZyN2eHt2eHvxZyPx ZyPxZyN2eHt2eHt2eHt2eHvxZyN2eHvxZyN2eHvxZyMjHyDxZyN2eHvxZyPxZyN2eHt2eHvxZyN2 eHt2eHvxZyN2eHvxZyN2eHvxZyPxZyN2eHsjHyCPc5fhAAAAfnRSTlMA+z/xCAz+XMLJ+Sau+Mn8 6+rJ4vjdSu/l9IqwP+wl/diPk4LV4qmXcUt0Ojofc0Y0uRQuDOnc0KFaFvS1sZ0Re3VTBtzEaNG/ UlKblr6KbWFazrtFQB8M89dEIHYq5dO0qaCQhikWwoBrajDal3pWS7WonnhiMyM6ZDdtHG6V4Br4 AAABAWlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iPz48cjpS REYgeG1sbnM6cj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+ PHI6RGVzY3JpcHRpb24geG1sbnM6eD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+PHg6 Q3JlYXRlRGF0ZT4yMDIxLTA0LTEzVDE1OjU3OjA0LTAwOjAwPC94OkNyZWF0ZURhdGU+PC9yOkRl c2NyaXB0aW9uPjwvcjpSREY+PD94cGFja2V0IGVuZD0iciI/PrF9NdgAAAuCSURBVHja1NpLbxJR GMbxB6ZN29FNAVmVsLeJC5JZTbpBEkJCSSiktMXa+/0Sq7Zq1fN+dZWpzDDPDAeYM6n+d1qt6S/H l3cuuNpZ8dr5Ak27O09/8utbjNRb8b7it/N4Cl2r3ezvun1MWqWbHTSPQf3GanZQ9wSa5la9v7ra eMCwk252fN0KvO5d17IPAVgyzLpAfJs5W4a9QLCORGU7udYV4pvPqEHl6xNM0txiWXktYFBWDStd Ylz7GfW3Izy1UFLaXmNQS7YfT1uSB1wJ1EFcFxJsF349V+JzOyuIqTL8CcoN6KsU1N++weu98ltE bP2CGpaZh1dTTdAt/nQlN+28c7EpL2FJsANEV5Sn+GTVZHzOxZiT5VWAvldq2AK8jlWgj4hri03x QU3SO/ypbsPqfJHdNTuEJTGDy4nFqoo2t63BUk3oWlCMhYLyK/dB8RnqwmtvCiy3Dse5s9CWMFYd UbUkFutQJqjWG491DV37UVjrKtCnCQ7We2bWY1k1OK6bx2fCkirA2fFYazJR7bFYJehaisLKqkDL +iOpjuE1X54CqyNwDiCnOZuw8uBeCmHR13TdjMNahq5FxvIGmV9Xq5zBU3OZKbAg2zcXaNXlM2HJ Oe9XYgBL7lLAulWB1gFurkDjfWqsorit87qsgbFchKsbwZKXRrF49hQA7pjO3vRYOM1ZrtMGGEsO MVpbzGBJyzzWvgp0Ce4VjfcpsG4RyhLqB60NE2LlDteeOujUbKGKxrEeVKA9UCfl0HhnrK2F728i e3fb12DxHn8uk2AxBoo5CWWZxOKTk6kg3EdF27uPpf+3GYtbQSB7ViygF+a6M471TgU6QriS8ltC JFYpIVYNtEfNhMXzbtc0FgqRQynqqqZhBIu7p7VhRix8sSVYziQWj/gHjLauCMUcFg+X7YRYOLXp aCXGohHOV9N87JqGsfhTviqJsPhbHJjGwrWK/cFf0/RPBcuGl5MMi6eeZRzrO82lSMclmMXiz62W GMCCS5+0CbH096v4f2jDMBbf2LKNYB3SBbVRrI9xlzyfFJGY27OcTujG1l3w1/WZsTYlUN0kFh+g W1qyaLzTBv/zdVTH2bFY1shJqo6uDb3ZsZCnoWUIi297XvOS5W3vhKVtcSyWPXJpk0eQ5wz52bEO xM82j3VJd5dpyVrC9FjrGiw4QR/xs3szYvHl5aZJLB7xnyKXrEYaWMXYuyszYvFFz6NJLB7xy1Hn rYQ0sJCTqBwkwlqRQFXzWP3giM+CJ1kzHayeLRHtzIzFS3zbKBbD7PvPcGl7N4yFG+HOMDMWP87+ mgLWN+W3hUFHPN7NY8GJvvYxNuB3zWHxiPef7i/TeE8Dqx19VW1qdZCeWSxe1jcAIEvj3fieBYBn fA1JsWr08Mg0VqUcWkD3abyncrJwStM9KZYtftupYGEj9GBii8Z77OVOfzUb1Ye+FotfX+ggKdZn enpoHmth9O7yJY130xfSNvj3xEZirDytWUax+Kr5BBs83s3comGXe/E7T4zVpufdaWA1ld8RCCM1 rOCMzyMxlkUrm1ksHvF7lzTeU8R6QSvk7FhnEqxoHotflykXaLynh+XP+DUkxVqjF5pSwmqoyJaQ Olav6tVLinVGDyTTwsKyiqqRGhaXDOurJSNtI0WspopoGf8JVpGe0F6lguV/Q675z2LdY3PQj82r aivn8quSse+UVh5WqWxfg8UjnspU/lksTXUQ1tjK7z9MhdXQjHfC8irEpfafD8sBYWk71mDpRnxj DJa+jWfDssBY+rLTYB2pUCUkwlp6LiwHM2HtTYHFBs3/E+sX+3bQgiAMhnH8lRZkR62z32HQsVsQ QZdmEHqwzCjCiCDp8weyKBounTAwnt9ZEf7M9yC+HpnFGtWLpV4lv2x18TUsyDBWwJvEun2fjA6e rOhIprEcpo2lH/GLlrHu9mP5MZGtWJk63s1jOdxyrOEpJ7ISS62wbBkrU/80M4mV19sKm4QrqsSD JjNLaDcp3gbKeDd9dnAgRRp5UjQlnbQ3k/z5xww6l/crwn0Rb0iHiWT8UyIYla4XVxLiQdXWwYtu E5jttq6WcDNO/4/1mUQAAAAAAAAAAADwbMdcdhSFgjBcq7PjspNLQkRANMEg0Yga4iVGY3Shm36O eYX/0cdThc3M2M70hJnEZOZbNCJ46tR36hSk//N7TNf0QuzGbyN6WcYWNvQUU1lKwJb+KD569MC6 UAA6F3pRfGBGT3EABUaUtmdpO1NeBvgP1yYWYHQAFPSadAAV/ETWiv4sATASWf2Hay7cMdHOBM70 iizgJj8R4vzxaU+hdk9k+bCkfxZ6/V6QPVYndIi59pfLvT07Tz+urGF1IGbjT/ThYnaLnDSZP6S+ 3SOKUspjO45IWKZlPJe0t3PKytmEvD6wSk9aVkrFrOyxOcG9B9tZOPG27MdlKLPxQsrMbno72cZx f3SPmlf785KEq9ktV5N6QjmtnOT4xp8HxGyrjNph4Y0UJOcZYgs3jODDyrpALVkaEBCNOtCUdKOH xObWZ6ALjSOzU9B4dMPmsYcTMKWWNTM42JJqch6XCdjQChq1kHnGuOEGHEDptFOUfWi2JKXKhDIh 24YmIhoDbPANeKNWbGEQxXWvjQH3ks8VZg+ymI7kXSDmE8PT9x71sgMovJOuDSSn4RG8xU5A8uUU AwOWBTfcrKeDFPCinHNzD3mqeDBmA4MaeFRzeHXEjAGYWWRBHwYGHDYCxMOFAy7DM1Dkiy4wJKIQ UGk+cKFGugbmdKNCQu3owtfG3FqWNWWBCKgmgeUaGnUlmks4Axf92dD3DnjZvPuz0pU7jnBZdClu OyzLkA23vvcsaVAbLldmDpu+xZAku4j5pORwHOALMGFZlWwIh0P7clKxLC63pUKoQ9gyt4hasQQy rvEry5LsdgrXRpbAwSds8QKDkw+bavNgEePKy1OuDQR1+U+VjmFjT8wIai2yzLoPLEjofy/rWhda znYtHOTuVDwutKy6LXCgY8KNLEWXZclvYw5iIdeC9TBtCO+VYMoa9msBUbMNfRprsimfpUQlCp7A MTqf08jVZ56kWSfBVid0QecuPGK5P8ry62AbEnrfy1qhex/09O7UYGfyo14TlVt45q3O2xgx5yWX fB5jD1//MakdCfo0CegCa1fvSY2N3kc9S+awVhhygd8xv5Wlr3FP1YM69yA9PZD3g6yHlTnAom+Y 37NzcWBZjRep5x5m1Mz35EJ4lPUFhuyeVozxzuY7Wd7HL6VTBRqgwyljlR0Oh8FwtNayOt/JWrKs prI8PXb4K1kBMCQhOo9ohfg+6JePZTVLFFGg4KaRtzAfZLHuUQ6D2tGHMqwbhoXZZ2RRidDESuKn JK9CiwdZWmqgV2L0/nbSyAqgpo+yaqvm+yJeaVCnl0FNn8iydvXdGfXqKRQoH2X1cfZRUTs6SIk5 AaMnsuSOZqfUCnxYfOyifJS11rLIlvn1+NE4a2Rh9ETWFbhIVM7Vkit7zOiJLMz5Bh0g5Sj0pj6S NYFSbV+yRFGjrZEVNrLMfKDZbgIpKJ46f7KiZZZABc9kHYD9aOkDUSOLn7X76/hBFnMEjlmwMaDG 3LQwXwclMHwqC/46MIGUXzmd4SRVgDt8kEUOYFM7THSbDenqhIpaVtrIeieUKr/ntrShsXIunlqW 1fQsfowzc9liIQmVzlEHrx5kUQXGyEiCMVtqZLnYyiHknpVAs5cMNEakYN0n1MiKWGgrwn1ONUHV 39Fl/0U223xMNZuqMoWSNUyK+ZpqBrHtrKbcNeaHesRixNUTefL90XH2Uv6LZsxBdTwRHcyT5LHP qGFcJU68oZqh6ThFQJpUjpsjD+MdM23EIc92u1dicjNJ/CkNkoLo7RjJd/2FHIEX/pfi34cr6/NP si7923xaluzef5vPypLX3X8cDw59BnmYtOMrQZDU1/S1k58AAAAASUVORK5CYIIAAA== --_004_B7E101389F0E4609B99393DFDC3D1CE2glbcorecom_--