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 1uBwtl-008bdC-0I for pgsql-performance@arkaria.postgresql.org; Mon, 05 May 2025 14:34:25 +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 1uBwtk-004DJh-34 for pgsql-performance@arkaria.postgresql.org; Mon, 05 May 2025 14:34:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uBwtj-004DJC-BM for pgsql-performance@lists.postgresql.org; Mon, 05 May 2025 14:34:23 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uBwtf-000H1u-2Q for pgsql-performance@lists.postgresql.org; Mon, 05 May 2025 14:34:22 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-30828fc17adso4331452a91.1 for ; Mon, 05 May 2025 07:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1746455659; x=1747060459; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cm3MdNw5KEA8KNh8LEQsIMSXT7ePTJ/3WhYdcH+Qhic=; b=NR3HLbtc47j3fB0xeMfY2+B/MsTUpY0zuyZF1XxMm/wFUiOK1YsmAVUsE8+iywQRw/ l4Ds3xw3vhs9sk4rcwknSaOygD25v1vSdwN54WM6adntw4bM5qgYUyMjqr6xcD3HxPQG z3gBt5bRrHPEPLX7UpCngWRpXowRCHb6/VbXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746455659; x=1747060459; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cm3MdNw5KEA8KNh8LEQsIMSXT7ePTJ/3WhYdcH+Qhic=; b=nJ1ZuP+ZTmfciA3c7SUylXZlOvkmfOx+7zHDgIxj6JsD6mzqbnx20XiGV6Eu7aoKFJ M/B5+Xc5szDBEQCDSeFgbriDqvSn62jfhf4BBVK4ePmpvdy2Qk1GQiX+ed7PONgJ/LVS r1F4j+Vxp/qYpq0F/6wVSBvU1rFCE8TAZDD6vim6k5TqVYyUxKruXbbh1UDpMU07zBRZ ZAKjAoYCLLtoglNeKp3lu6EdjWe2wEc2urgDerOv4COfqZIyjHxZfk3SoRd1Pfy0cG95 V9C8r29Ym5z92P+Hr81lgbuEo9pXHJnfHQDHRKyQTs5Ouz0+o+pPaostockQ8sc+vl5e OrhA== X-Forwarded-Encrypted: i=1; AJvYcCV5MSAraM1F1YJTTJ6mdoqzrsJGM/JznLPZ0gBdiwjWxyl6v+anf4Zw1Mn2byr0HXJbWNRp76cIoRGmGujpDsk9SA==@lists.postgresql.org X-Gm-Message-State: AOJu0YyUWVuIQRwoVtyVnjbperMI9uigv7UmR+VMyIjwOS5ACm61bIu+ W4YSN59cE4RkPa2RZrxifuZVS1cfZ7Ruv9TMENXOmr8q5dKYtcNxAwjaMf9wvWULAC5pXMzcctk gyL7RqHMRbIcRIsY4ydrgV+/odmTas00tmH5N52QGhrrsoGGmMK3SwYupNUFXmU79GJtTLi9gmO JUpxomCbJThKJnn1ATfbXwUJzHjOdxqQudSOrX4Vc= X-Gm-Gg: ASbGncvEOwBa8byxe9URQlgEtKcgUH8RJnevx0bjZDu76KHQMGiPQRmiN+kh0hAHZQ6 8h+A7pZU9FEc/CjJKt04vM66QqpquZL2NAYxzXyQiNmlN8YJupkaV/3Y6QEJT2uCmMjZvJb47Od iOVIUtLOi51eoiIqUeT7zmn2I7RJNCHDU5ADeq8L1v5wtAhQpFFycQ X-Google-Smtp-Source: AGHT+IFABWl3LJWLFtuy+bLH8LwXiNM3UPHkUnF4kOLv5arKjCeAX7YMCSfQ2IlfL6w5denuDmhHYJBUp+fPJQ5MfPA= X-Received: by 2002:a17:90b:5626:b0:30a:2007:65b6 with SMTP id 98e67ed59e1d1-30a61a5071dmr9980653a91.34.1746455658178; Mon, 05 May 2025 07:34:18 -0700 (PDT) MIME-Version: 1.0 References: <000001dbbc64$163f99e0$42becda0$@msym.fr> In-Reply-To: <000001dbbc64$163f99e0$42becda0$@msym.fr> From: Craig Jackson Date: Mon, 5 May 2025 08:33:40 -0600 X-Gm-Features: ATxdqUHdoioVonBoDj2ekO505wZQi_8v28-PV4KLXMqyjozYOvzNRxf_xIlnHAA Message-ID: Subject: Re: Vacuum Questions To: msalais@msym.fr Cc: Leo , pgsql-performance@lists.postgresql.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002d0d8d06346465a2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002d0d8d06346465a2 Content-Type: multipart/alternative; boundary="0000000000001f5e11063464656a" --0000000000001f5e11063464656a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the two indexes that take 12 hours to vacuum: If you can drop and rebuild them in less than the 12 hours it takes to vacuum them and you can have them be offline then I would do that. If you can't take the indexes offline then consider reindexing online. Also, if the indexes aren't needed for your delete statements, dropping the indexes before your start the deletion work would allow you to avoid the overhead of maintaining the indexes, possibly speeding up the delete statements. Craig Jackson On Sat, May 3, 2025 at 1:46=E2=80=AFPM wrote: > Hi > > > > It is not your question but for such situations, you should consider usin= g > partitioning. > > And more closely to your question: I would not disable autovacuum but it > must not work with default values. > > > > Best regards > > > > *Michel SALAIS* > > *De :* Leo > *Envoy=C3=A9 :* vendredi 2 mai 2025 16:23 > *=C3=80 :* pgsql-performance@lists.postgresql.org > *Objet :* Vacuum Questions > > > > I have been working on AWS PostgreSQL RDS for a few years, but still not > very experienced when it comes to performance issues. Plus RDS is slight= ly > different from the pure PostgreSQL. > > > > I am trying to comprehend exactly how vacuum works. > > > > Here is what I am trying to do. > > > > I am purging old records from a table (500 million rows, but I am doing i= t > in sets of 50,000,000 with a smaller loop of 100,000). That works just > fine. > > > > Because of the amount of data/rows deleted, I disabled the autovacuum for > this table (I want to have control over vacuum, autovacuum does not > complete anyway due to the timeout, sizing, etc settings that I do not wa= nt > to change system wide). I will put the autovacuum back once I am done of > course. > > > > The issue is when I start vacuuming. This table has 4 indexes and a PK > that I worry about. The PK takes about 30 minutes to vacuum and two of t= he > indexes take about an hour each. The problem comes in for the other 2 > indexes - they take 12+ hours each to vacuum: > > > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: vacuuming > "public.pc_workflowlog" > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: launched 4 parallel vacuum > workers for index vacuuming (planned: 4) > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: scanned index > "pc_workflowlog_pk" to remove 50000000 row versions > > DETAIL: CPU: user: 191.03 s, system: 12.43 s, elapsed: 1711.22 s > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: scanned index > "workflowlo_u_publicid_g6uqp9lkn6e8" to remove 50000000 row versions > > DETAIL: CPU: user: 325.75 s, system: 19.75 s, elapsed: 2674.24 s > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: scanned index > "workflowlo_n_workflow_2tc9k2hdtry9v" to remove 50000000 row versions > > DETAIL: CPU: user: 312.17 s, system: 16.94 s, elapsed: 3097.88 s > > *psql:/home/backup/leo/fws_vacuum.sql:6: INFO: scanned index > "workflowlo_n_frozenseti_2kjkbjgf3c6ro" to remove 50000000 row versions* > > *DETAIL: CPU: user: 41187.70 s, system: 216.14 s, elapsed: 42749.36 s* > > *psql:/home/backup/leo/fws_vacuum.sql:6: INFO: scanned index > "workflowlo_n_userid_14kqw6qdsnndw" to remove 50000000 row versions * > > *DETAIL: CPU: user: 41280.66 s, system: 216.67 s, elapsed: 42832.16 s* > > psql:/home/backup/leo/fws_vacuum.sql:6: INFO: "pc_workflowlog": removed > 50000000 row versions in 1129870 pages > > > > I've increased max_parallel_maintenance_workers to 8 for the session and > it used parallel 4 (one for each index I assume) to handle it and the two > indexes were done in ~ an hour. What I am trying to figure out is how to > force the other two large indexes to be vacuumed in parallel - a few > workers going against an index. It seems it is possible to do, the index > size is large enough to kick in, but I have not been able to figure it ou= t > yet. Most of the parameters are at default values. > > > > What am I missing? > > > > I have a few other questions. Does vacuum time depend on the number of > dead rows only and the size of the table, or does the entire storage > allocation (including dead tuples) also affect it? > > > > Would it be more beneficial to drop the two large indexes, purge, vacuum, > and recreate the indexes after make more sense (I know it needs to be > tested)? The reason I am doing it in stages is to make sure I have enoug= h > time to vacuum, but maybe it would not take much longer to vacuum after t= he > complete purge? > > > > Lastly, is it better to delete all the rows (500 mil) instead of doing it > in smaller batches, and vacuum only once? > > > > The current size of the table is about 1T and the indexes add another 1.5= T > to it. > > > > Truncate is not an option as I am only deleting rows older than 6 months. > Client was not doing purging for years, but will do it after the clean up= . > > > > P.S. This is my very first post here, please advise if it is the wrong > channel. Thank you in advance. > --=20 Craig --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000001f5e11063464656a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the two indexes that take 12 hours to vacuum: If you c= an drop and rebuild them in less than the 12 hours it takes to vacuum them = and you can have them be offline then I would do that. If you can't tak= e the indexes offline then consider=C2=A0reindexing online.=C2=A0

Al= so, if the indexes aren't needed for your delete statements, dropping t= he indexes before your start the deletion work would allow you to avoid the= overhead of maintaining the indexes, possibly speeding up the delete state= ments.=C2=A0=C2=A0

Craig Jackson

On Sat, May 3,= 2025 at 1:46=E2=80=AFPM <msalais@msy= m.fr> wrote:

Hi

=C2=A0

=

It is not your question but for such situations, y= ou should consider using partitioning.

And more closely to your question: I would not disable autovac= uum but it must not work with default values.

=C2=A0

<= span lang=3D"EN-US" style=3D"font-size:11pt;font-family:Calibri,sans-serif"= >Best regards

=C2= =A0

Michel SALAIS=

De=C2=A0: Leo <leo1969@gmail.com>
Envoy=C3=A9=C2=A0: vendredi 2 mai= 2025 16:23
=C3=80=C2=A0: pgsql-performance@lists.postgresql.org=
Objet=C2=A0: Vacuum Questions

=

=C2=A0

= I have been working on AWS PostgreSQL RDS for a few years, but still not ve= ry experienced=C2=A0when it comes to performance issues.=C2=A0 Plus RDS is = slightly different from the pure=C2=A0PostgreSQL.

=C2=A0

I am trying=C2=A0to comprehend=C2=A0exactly how vacuum works.<= /u>

=C2=A0

Here is what I am trying to do.

=C2=A0

I am purging old records from a table (500 million rows, but= I am doing it in sets of=C2=A0 50,000,000 with a smaller loop of 100,000).= =C2=A0 That works just fine.

=C2=A0

Because of t= he amount of data/rows deleted, I disabled=C2=A0the autovacuum for this tab= le (I want to have control over vacuum, autovacuum does not complete anyway= due to the timeout, sizing, etc settings that I do not want to change syst= em wide).=C2=A0 I will put the autovacuum back once I am done of course.=

=C2=A0

The issue is when I start vacuuming.=C2=A0 = This table has 4 indexes and a PK that I worry about.=C2=A0 The PK takes ab= out 30 minutes to vacuum and two of the indexes take about an hour each.=C2= =A0 The problem comes in for the other 2 indexes - they take 12+ hours each= to vacuum:

=C2= =A0

psql= :/home/backup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0vacuuming "public= .pc_workflowlog"

psql:/home/backup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0l= aunched 4 parallel vacuum workers for index vacuuming (planned: 4)

psql:/home/ba= ckup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0scanned index "pc_workflow= log_pk" to remove 50000000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 191.0= 3 s, system: 12.43 s, elapsed: 1711.22 s

psql:/home/backup/leo/fws_vacuum.sql:= 6: INFO:=C2=A0=C2=A0scanned index "workflowlo_u_publicid_g6uqp9lkn6e8&= quot; to remove 50000000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 325.75 s, sy= stem: 19.75 s, elapsed: 2674.24 s

psql:/home/backup/leo/fws_vacuum.sql:6: INFO:= =C2=A0=C2=A0scanned index "workflowlo_n_workflow_2tc9k2hdtry9v" t= o remove 50000000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 312.17 s, system: 1= 6.94 s, elapsed: 3097.88 s

psql:/home/backup/leo/fws_vacuum.sql:6: INFO:=C2= =A0=C2=A0scanned index "workflowlo_n_frozenseti_2kjkbjgf3c6ro" to= remove 50000000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 41187.70 s, s= ystem: 216.14 s, elapsed: 42749.36 s

psql:/home/backup/leo/fws_vacuum.s= ql:6: INFO:=C2=A0=C2=A0scanned index "workflowlo_n_userid_14kqw6qdsnnd= w" to remove 50000000 row versions=C2=A0

<= p style=3D"margin:0cm;font-variant-numeric:normal;font-variant-east-asian:n= ormal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:aut= o;font-feature-settings:normal;font-stretch:normal">DETAIL:=C2=A0=C2=A0CPU: use= r: 41280.66 s, system: 216.67 s, elapsed: 42832.16 s

psql:/home/backup/leo/= fws_vacuum.sql:6: INFO:=C2=A0=C2=A0"pc_workflowlog": removed 5000= 0000 row versions in 1129870 pages

=C2=A0

I've increased=C2=A0max_parallel_maintenance_workers to 8 for the sess= ion and it used parallel 4 (one for each index I assume) to handle it and t= he two indexes were done in ~ an hour.=C2=A0 What I am trying to figure out= is how to force the other two large indexes to be vacuumed in parallel - a= few workers going against an index.=C2=A0 It seems it is possible to do, t= he index size is large enough to kick in, but I have not been able to figur= e it out yet.=C2=A0 Most of the parameters are at default values.=

=C2=A0

What am I missing?

=C2=A0

I have a few other questions.=C2=A0 Does vacuum=C2=A0time depend on the = number of dead rows only and the size of the table, or does the entire stor= age allocation (including dead tuples) also affect it?

=C2=A0

Would it be more beneficial to drop the two large indexes, p= urge, vacuum, and recreate the indexes after make more sense (I know it nee= ds to be tested)?=C2=A0 The reason I am doing it in stages is to make sure = I have enough time to vacuum, but maybe it would not take much longer to va= cuum after the complete purge?

=C2=A0

Lastly, is= it better to delete all the rows (500 mil) instead of doing it in smaller = batches, and vacuum only once?

=C2=A0

The curren= t size of the table is about 1T and the indexes add another 1.5T to it.<= /u>

=C2=A0

Truncate is not an option as I am only delet= ing rows older than 6 months.=C2=A0 Client was not doing purging for years,= but will do it after the clean up.

=C2=A0

P.S. = This is my very first post here, please advise if it is the wrong channel.= =C2=A0 Thank you in advance.



--
Craig=C2=A0

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --0000000000001f5e11063464656a-- --0000000000002d0d8d06346465a2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQYwYJKoZIhvcNAQcCoIIQVDCCEFACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3HMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBU8wggQ3oAMCAQICDE2yXBrcHZ6szwbIQzANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA4MjkwOTQ2NThaFw0yNTA4MjkwOTQ2NThaMIGQ MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFjAUBgNVBAMTDUNyYWlnIEphY2tzb24xKTAnBgkqhkiG9w0B CQEWGmNyYWlnLmphY2tzb25AYnJvYWRjb20uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAvUqzLPMYW9DT6zgh+LzzhRAWFg4L+kvrbQQIzqStD6L3ODDUeHJ5ZJtXlIZZN6pcWG5O 409+QlpX3HShfC3WRe0K0VoXizXVDTaD5T4zEvEpadbcYegolA8OGRzd9MLCzjmNVNtehcEjviIy rjZA/Rc4tmeLr/sjk8wr0nStCXoejU7iuLUou2SknQZSBCAy5KzDo+KcUw1nLDOgvHAPn1JN3t9A Ks5Ey7Pekds9/EYI2/cjMoy6w1dZFQK1L3GUkyaCsh8u27aseksyPk8PxLxnHLx2DrrQJnA0QmTp RzTyk6paE0xzfl4H4j39H9zj470Q2PYaslpxKeGbjg6FOwIDAQABo4IB2zCCAdcwDgYDVR0PAQH/ BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0cDovL3NlY3VyZS5nbG9i YWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3J0MEEGCCsGAQUF BzABhjVodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAy MDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xv YmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6hjhodHRw Oi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwLmNybDAlBgNV HREEHjAcgRpjcmFpZy5qYWNrc29uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAf BgNVHSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUk0YMkKNxAf14/U70on32 qJAPCfkwDQYJKoZIhvcNAQELBQADggEBADbCwHxdqLH5Up3Q44WpPgt5asXlxyDDWEAWMREOIP3W QKu8JlS0JBzn32NrNsCf1Llt9iZSa4EOy7J1o/+MhkFKQPDsFrCaZGEZyncUw34oJvHRibBMwkKT L/UXmIFXBQ3lLE2WjCkqH7Lyg3so98P0FX+yLJhznvG7V9cLjztaYddhhyAVxDk4YEpnv4xJRr5x fuiu3YntjesTWoYPvY8neTxXM9QWZ5XloxTi2zhCFC9p4ce5UjAOjywEP6IsAoOgH6I6sKN10Pn5 qUojNTiyQhz4unKkqCoM42StVUlQwyMNmlhtHtfPtxrccnu/ybGKlA5eslpkcklGrjEd2qMxggJg MIICXAIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYD VQQDEyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgxNslwa3B2erM8G yEMwDQYJYIZIAWUDBAIBBQCggccwLwYJKoZIhvcNAQkEMSIEIES/tml3CnMlhttDA82i2De47ZKx CuabYsT0kUuo3u82MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1 MDUwNTE0MzQxOVowXAYJKoZIhvcNAQkPMU8wTTALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3 DQEBAQUABIIBAF8viFDLbcknEdShcT701j1PW+nKlXsjftOWt4wGjiqpkUvk2WVuSPnmthcagZA2 MxDGr4ZKDVIdMqLwsMx19zmdul5+d8184rjqcfMSpB9MUt4ztoIN+BgPmHdT5uWOnL0mD6buyFuI HhrhUhDLoxfXRZQngj8lvKHQ5h/rWOcmfgXADNNYA5P7xz3EfJLlblQmF59t1v/0SolbnEAJlR1C l0M+/jVEzqtUxZV/v13F8BdpmbokIrs0fbMN658XQ+lJudnAmA2vc7xs7ev/HP/BLdwOOk5jpB84 tTUWGX+8H32mTMp5Aq4zFbyzhYdObnI8cE31it9+CoAO/NsXjIM= --0000000000002d0d8d06346465a2--