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 1uBwvO-008bvv-Kf for pgsql-performance@arkaria.postgresql.org; Mon, 05 May 2025 14:36:07 +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 1uBwvN-004Fhz-Nw for pgsql-performance@arkaria.postgresql.org; Mon, 05 May 2025 14:36:05 +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 1uBwvM-004Fhp-J9 for pgsql-performance@lists.postgresql.org; Mon, 05 May 2025 14:36:04 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uBwvJ-000H34-1C for pgsql-performance@lists.postgresql.org; Mon, 05 May 2025 14:36:03 +0000 Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-736c3e7b390so5138164b3a.2 for ; Mon, 05 May 2025 07:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1746455761; x=1747060561; 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=+WUX1a+IgBUdWPoUCf93A7rCtgrV/RIjOPCXYojA7Y0=; b=SZKb+BC+/+qu+DyQj8zlBV/lnTOsWM5t9lVrMjHtgqY1ILschPq44p7UFQH1g7fWSw 3N9+stC1NTT4SD/jJcrGiy/56M+W7+60ZHs2rVD2dZaapkaFpLMa5TxC7cql/o0nntL3 rPe6ZjwVD+y6FtVbKpM6sWQetTnlHc7zb2SL8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746455761; x=1747060561; 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=+WUX1a+IgBUdWPoUCf93A7rCtgrV/RIjOPCXYojA7Y0=; b=IybvhJUhGev+nnxX+LPFKHiiE07bSj7Sp+LpBPyEMbNMX8LkXC3PkbbmZmW0sG1jzq Zxcuy6BXykMLEqi910+eS+O+cnJML7uJcnriyyQpjFe5i+HYRpzXkcpl28Zzy0q7+7NZ 9bpgVLEGxn8xEhuWs5UCvuVJWRnfZzL9TAoGKiFGx4XgKBJw4DE2+yFYkKG+7Yn9slwx Sc4yWwiJ8yCKVo5kT2FTM5xa+5fMivi67MVzlJQgwOzsRwW1Z8CUjEDOFNqfheEK12/E jTW6lUBqtienbwT88kcXfPHimf0hHWBxPHxyceWPM0YgbAGhayzualchOiGBXz4SiTj5 XftA== X-Forwarded-Encrypted: i=1; AJvYcCU70gJL4o4jqgmgintNWlhHsB1J7fZeqF8HtA6jyiu3H4UVJ1o/OOm0eJzvHQwxcJ0YH3a04MNt6MVk/Yxz2YSZMQ==@lists.postgresql.org X-Gm-Message-State: AOJu0YyB4vwNHU4Mle5rjhKEE84VrKNM/eMUPb/EqArPJwg0zORpr2fr 6FGb4LsxtHETviTMA8Mn5mMvLfkQTlECisKcB0uwqpoD6sZ+r2gRiQoMLjGPU9dKKN0jmI9I6cC gyJxljaYUC5OeNPoe7ao+XUD4ubD8CmxHbjeAa21Ygk8psa5osSonTO9WNOwSH51FgTVtmkmMkM VB/xnSDBFsvR+658lAgE7fH0q9ctkHRjv6qcBchZAPEhqfVWTZVCMJvmM= X-Gm-Gg: ASbGncuK16iiG8JI3FHeIKeyiD1xInwb/5KRGcsKgUMH/SMfmKODG5OKO86xdVn4sRX kuIYc6CM+BpMljmH4IYt5Oo22qNGtGVC0PJUFSiHvDa6hg3hpnpTprL1EV2FeQ61BMazkfhEeN2 qfgGUlMswooYSBlCeT92ySu4O2XL7Yp+TztuJU9z8I7qgUp2vcvCo6 X-Google-Smtp-Source: AGHT+IEL9j5FfD588RVlhCHkFoU2DJpt4B2P0EjVGOfTUD7iDoD26YH2uVoXdlusNHEy0dC8C0dhaq2v4kFl01RIlEc= X-Received: by 2002:a17:90b:5748:b0:2fe:e0a9:49d4 with SMTP id 98e67ed59e1d1-30a6196bd67mr10887403a91.2.1746455761087; Mon, 05 May 2025 07:36:01 -0700 (PDT) MIME-Version: 1.0 References: <000001dbbc64$163f99e0$42becda0$@msym.fr> In-Reply-To: From: Craig Jackson Date: Mon, 5 May 2025 08:35:24 -0600 X-Gm-Features: ATxdqUG9g1bzE2dADbNIJumKjPMVuakrfILoSa8CKwyhiLi_usxbmdoQ5PtZ_Es 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="000000000000499e1f0634646bf7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000499e1f0634646bf7 Content-Type: multipart/alternative; boundary="000000000000419b630634646b61" --000000000000419b630634646b61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One additional point about reindexing I should have mentioned, make sure you have adequate disk space to complete the reindexing. Craig On Mon, May 5, 2025 at 8:33=E2=80=AFAM Craig Jackson wrote: > 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 ca= n > 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 >> using 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 sligh= tly >> 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 >> it in sets of 50,000,000 with a smaller loop of 100,000). That works j= ust >> fine. >> >> >> >> Because of the amount of data/rows deleted, I disabled the autovacuum fo= r >> 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 w= ant >> to change system wide). I will put the autovacuum back once I am done o= f >> 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 = the >> 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 vacuu= m >> 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 tw= o >> indexes were done in ~ an hour. What I am trying to figure out is how t= o >> 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 inde= x >> size is large enough to kick in, but I have not been able to figure it o= ut >> 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 enou= gh >> time to vacuum, but maybe it would not take much longer to vacuum after = the >> complete purge? >> >> >> >> Lastly, is it better to delete all the rows (500 mil) instead of doing i= t >> in smaller batches, and vacuum only once? >> >> >> >> The current size of the table is about 1T and the indexes add another >> 1.5T 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 th= e >> clean up. >> >> >> >> P.S. This is my very first post here, please advise if it is the wrong >> channel. Thank you in advance. >> > > > -- > Craig > --=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. --000000000000419b630634646b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One additional point about reindexing I should have mentio= ned, make sure you have adequate disk space to complete the reindexing.=C2= =A0

Craig

On Mon, May 5, 2025= at 8:33=E2=80=AFAM Craig Jackson <craig.jackson@broadcom.com> wrote:
For the two indexes tha= t take 12 hours to vacuum: If you can drop and rebuild them in less than th= e 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=C2= =A0reindexing online.=C2=A0

Also, if the indexes aren't needed f= or your delete statements, dropping the indexes before your start the delet= ion work would allow you to avoid the overhead of maintaining the indexes, = possibly speeding up the delete statements.=C2=A0=C2=A0

Craig Jackso= n

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

H= i

=C2=A0

It is not your question but for such situations, you shoul= d consider using partitioning.

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

=C2=A0

Best re= gards

=C2=A0=

Michel SALAIS

D= e=C2=A0: Leo <leo19= 69@gmail.com>
Envoy=C3=A9=C2=A0: vendredi 2 mai 2025 16:2= 3
=C3=80=C2=A0: pgsql-performance@lists.postgresql.org
Objet=C2=A0: Vacuum Questions

=C2=A0

I have b= een working on AWS PostgreSQL RDS for a few years, but still not very exper= ienced=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.

<= /div>

=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 do= ing it in sets of=C2=A0 50,000,000 with a smaller loop of 100,000).=C2=A0 T= hat works just fine.

= =C2=A0

Because of the amoun= t of data/rows deleted, I disabled=C2=A0the autovacuum for this table (I wa= nt to have control over vacuum, autovacuum does not complete anyway due to = the timeout, sizing, etc settings that I do not want to change system wide)= .=C2=A0 I will put the autovacuum back once I am done of course.<= /u>

=C2=A0

The issue is when I start vacuuming.=C2=A0 This tab= le has 4 indexes and a PK that I worry about.=C2=A0 The PK takes about 30 m= inutes 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 vacu= um:

=C2=A0=

psql:/home/bac= kup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0vacuuming "public.pc_workfl= owlog"

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

psql:/home/backup/leo/f= ws_vacuum.sql:6: INFO:=C2=A0=C2=A0scanned index "pc_workflowlog_pk&quo= t; to remove 50000000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 191.03 s, syste= m: 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" to re= move 50000000 row versions

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

psql:/home/backup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0= scanned index "workflowlo_n_workflow_2tc9k2hdtry9v" to remove 500= 00000 row versions

DETAIL:=C2=A0=C2=A0CPU: user: 312.17 s, system: 16.94 s, elap= sed: 3097.88 s

psql:/home/backup/leo/fws_vacuum.sql:6: INFO:=C2=A0=C2=A0scann= ed index "workflowlo_n_frozenseti_2kjkbjgf3c6ro" to remove 500000= 00 row versions

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

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

DETAIL:=C2=A0=C2=A0CPU: user: 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 50000000 row versio= ns in 1129870 pages

=C2=A0

I've incre= ased=C2=A0max_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.=C2=A0 What I am trying to figure out is how to forc= e the other two large indexes to be vacuumed in parallel - a few workers go= ing against an index.=C2=A0 It seems it is possible to do, the index size i= s large enough to kick in, but I have not been able to figure it out yet.= =C2=A0 Most of the parameters are at default values.

=C2=A0

What am I missing?

=C2=A0

I have a f= ew other questions.=C2=A0 Does vacuum=C2=A0time depend on the number of dea= d rows only and the size of the table, or does the entire storage allocatio= n (including dead tuples) also affect it?

=C2=A0

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 teste= d)?=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 vacuum 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 v= acuum only once?

= =C2=A0

The current size of the = table is about 1T and the indexes add another 1.5T to it.

=

=C2=A0

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

=C2=A0

P.S. This is my ver= y first post here, please advise if it is the wrong channel.=C2=A0 Thank yo= u in advance.

<= /div>


--
Craig=C2=A0


--
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. --000000000000419b630634646b61-- --000000000000499e1f0634646bf7 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 yEMwDQYJYIZIAWUDBAIBBQCggccwLwYJKoZIhvcNAQkEMSIEIDWOy32TGjHa+r+JkbMS5pdNq2+A C0JwzGYA8lzDvbrKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1 MDUwNTE0MzYwMVowXAYJKoZIhvcNAQkPMU8wTTALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3 DQEBAQUABIIBAFFWiYthhy339bGAts9FkTW2Lkp1KcgnKR3Wk4awZyAEpz37kQY0euKVQfS4nFVF rLoGPdpbPs3dZYpiYxWgYQoPNDjsswPCBgjhh6otGUDqtJhZgnoquZvw3Yl8HTHfi9SEdayBLHnp yvNbYraxt9WKHTT7X6faspy8XT1qdCFkLoARqw6YKQhYRty3lI2PEvawv3v6OF1nFDe7puH4vSBW LA5STmbrspMt+3x/a9G+o9VEbtOdqm5nG8Zw3CN0yON9acHNq/2HK7jWPzee017Btqydshda8VI0 GJHGNrF+4oBfpgYHAMskBaY6k0Pi5HmD1NI9zQQqFvEJxV0UMyA= --000000000000499e1f0634646bf7--