Content-Type: multipart/mixed; boundary="------------Hcnbij6pmtNMrGS1Vk5HHQQ5"
Message-ID: <2d7c4e54-6a0b-4b1a-87a6-278c49fa52f0@dunslane.net>
Date: Wed, 1 Apr 2026 07:15:40 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: scale parallel_tuple_cost by tuple width
To: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <e9f24286-068e-40cb-a6a9-25a4f938672a@dunslane.net>
 <2005009.1774880253@sss.pgh.pa.us>
 <CAApHDvpOPs-Ywcze5=eyi4s5hO1NM9RA8No20Q=s+0L3LiorHw@mail.gmail.com>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAlwQTAQgAQQIbAwIX
 gAIZAQULCQgHAwUVCgkICwUWAgMBAAIeBRYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNGd
 BQkdEO8nAAoJEJn6f8tZ/DuBq74H/jkTR4Zi3stbw+xC7v2u3QozssK7MYPL2AsVfh7OealS
 h182fiWXpfvmmAB7WUHbhk9GC2RAOnHI/2d2jgKaMLAHsGYOT0YopTVIwRY43fCw/mK67yxc
 wmDcX+zyKfLaivNbf5A7QPLNwda98bEAMSJ8Sn652Uc6cA8t3uKGsVzbRBQOoYzjgvBCfSrE
 9ql3PDNg0l4BfAqabd2f70ZUm9VAMEPrgv/v2xI7M2XiL4g5BVmqLCOwxLM8RMCotCuoweUr
 VO43DeBCIDwLxotMJKvGWDjBzQYlU1NPUAtNcz/gN9ITUe1VUGjyvGj4u1lxBOcQQUw7l1+T
 5moZ4iZxXzvOwE0ETspYWQEIANGc4zQULOxhbqO2dyD51YhqCNRmm9oKWaqf+wmW4tpDe/VV
 cxAnNizd4LWCHfzpb5cHAtGkOPePMfzWVf6nvdF7d3eglbtf59+zG7O7llV0xSSoFiieQBsr
 GvqDInXYX/4mRRXMtyhM353/tixC9RWLs1oofyYmCPPXXY7h9R7en3B8BoVrRFcdzlIY/NFN
 hFGW/9dkEiGjgna2Rk6e15kln4ZvFBWUg23p93w/pqXcxY6+k/8TEk+C4R+M6w7o2PLGOjdZ
 +kPiUcw5H85zf/yZJwQXzisXaNduwWB6Vads9YC9dj6kPR1c4VGRqAaYL++LAEOqrlvm2Tvq
 QqZRtnEAEQEAAcLAfAQYAQgAJgIbDBYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNI2BQkd
 EODdAAoJEJn6f8tZ/DuBfw0IAKTsfD40teP/pp+bsLLMSxPXUYrrprTj7WFB5v61p6dkpSr/
 qXmMlyahdxQFaPmfVgVirB1Vk/kHiWNnnGjfUV9nB2Zg9LI0Xb9/ts3LsUiRWXzG3tkMY6XL
 vsVOxW4XFRND9l2q+WW93aZ1DZl+fqWfYgMvsusFRhmGFOKTRfKPta2Pkv+AhA24N4+PrR5p
 bU4k2MO8PAGiK8eaYKGFG1bHKuAvoDoF7WXJ3FHxuWqLnKEt4dfOLm5pAe3zq1Lt6q8azT9i
 QWGpSAK5vQUWQHBHpiDjdPeqKZ6HiAXIIKfSmb+jrvXBqoP+D6/K7rUjG2aXiRtTIAXms9sm
 VRu7cmw=
In-Reply-To: 
 <CAApHDvpOPs-Ywcze5=eyi4s5hO1NM9RA8No20Q=s+0L3LiorHw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/2d7c4e54-6a0b-4b1a-87a6-278c49fa52f0%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------Hcnbij6pmtNMrGS1Vk5HHQQ5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 2026-03-30 Mo 6:51 PM, David Rowley wrote:
> On Tue, 31 Mar 2026 at 03:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> While investigating a performance issue, I found that it was extremely
>>> difficult to get a parallel plan in some cases due to the fixed
>>> parallel_tuple_cost. But this cost is not really fixed - it's going to
>>> be larger for larger tuples. So this proposal adjusts the cost used
>>> according to how large we expect the results to be.
>> Unfortunately, I'm afraid that this is going to produce mostly
>> "garbage in, garbage out" estimates, because our opinion of how wide
>> tuples-in-flight are is pretty shaky.  (See get_expr_width and
>> particularly get_typavgwidth, and note that we only have good
>> statistics-based numbers for plain Vars not function outputs.)
>> I agree that it could be useful to have some kind of adjustment here,
>> but I fear that linear scaling is putting way too much faith in the
>> quality of the data.
> (I suspect you're saying this because of the "Benchmark 2" in the text
> file, which contains aggregates which return a varlena type, of which
> we won't estimate the width very well for...)
>
> Sure, it's certainly true that there are cases where we don't get the
> width estimate right, but that's not stopped us using them before. So
> why is this case so much more critical?  We now also have GROUP BY
> before join abilities in the planner, which I suspect must also be
> putting trust into the very same thing. Also, varlena-returning
> Aggrefs aren't going to be the Gather/GatherMerge targetlist, so why
> avoid making improvements in this area because we're not great at one
> of the things that could be in the targetlist?
>
> For the patch and the analysis: This reminds me of [1], where some
> reverse-engineering of costs from query run-times was done, which
> ended up figuring out what we set APPEND_CPU_COST_MULTIPLIER to. To
> get that for this case would require various tests with different
> tuple widths and ensuring that the costs scale linearly with the
> run-time of the query with the patched version. Of course, the test
> query would have to have perfect width estimates, but that could be
> easy enough to do by populating a text typed GROUP BY column and
> populating that with all the same width of text for each of the tests
> before increasing the width for the next test, using a fixed-width
> aggregate each time, e.g count(*). The "#define
> PARALLEL_TUPLE_COST_REF_WIDTH 100" does seem to be quite a round
> number. It would be good to know how close this is to reality.
> Ideally, it would be good to see results from an Apple M<something>
> chip and recent x86. In my experience, these produce very different
> performance results, so it might be nice to find a value that is
> somewhere in the middle of what we get from those machines. I suspect
> having the GROUP BY column with text widths from 8 to 1024, increasing
> in powers of two would be enough data points.


I followed your suggested methodology to measure how Gather IPC
cost actually scales with tuple width.

Setup: 10M rows, 100K distinct text values per table, text column
padded to a fixed width with lpad().  Query: SELECT txt, count(*)
FROM ptc_bench_W GROUP BY txt.  This produces Partial HashAggregate
in workers, then Gather passes ~240K partial-aggregate tuples whose
width is dominated by the text column.  2 workers, work_mem=256MB,
cassert=off, debugoptimized build, aarch64 Linux.

I tested widths from 8 to 1024 bytes (10 data points).  For each
width, I ran 5 iterations of both parallel and serial execution,
and computed the Gather overhead as:

   overhead = T_parallel - T_serial / 3

This isolates the IPC cost: the serial time captures pure scan +
aggregate work, and dividing by 3 gives the ideal parallel time
(2 workers + leader).  The excess is Gather overhead.

Results (microseconds per tuple through Gather, median of 5 runs):

   Width(B)  us/tuple   Implied ptc (if ptc=0.1 at w=100)
   --------  --------   ----------------------------------
          8     0.30     0.032
         16     0.24     0.025
         32     0.77     0.083
         64     0.72     0.078
        128     1.03     0.111
        256     1.62     0.175
        384     2.90     0.313
        512     3.21     0.346
        768     4.12     0.445
       1024     5.56     0.600

The best-fit models:

   Linear:    cost(w) = 0.42 + 0.0051 * w     R² = 0.983
   Power law: cost(w) = 0.061 * w^0.63         R² = 0.966

Linear fits best.

One notable finding: at the proposed reference width of 100 bytes,
the total predicted cost is 0.42 + 0.51 = 0.93 us/tuple, of
which 0.42 is fixed.
The original patch used PARALLEL_TUPLE_COST_FIXED_FRAC = 0.10,
which substantially underestimates the width-independent component.
A higher fixed fraction would dampen the width adjustment, which
also partly addresses Tom's concern about sensitivity to width
estimate errors: with ~45% of the cost being fixed, even a 2x
error in width only translates to a ~1.5x error in total cost.

The script used to get the timings is attached.

cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

--------------Hcnbij6pmtNMrGS1Vk5HHQQ5
Content-Type: application/x-shellscript; name="ptc_calibrate.sh"
Content-Disposition: attachment; filename="ptc_calibrate.sh"
Content-Transfer-Encoding: base64

IyEvYmluL2Jhc2gKIyBQYXJhbGxlbCB0dXBsZSBjb3N0IGNhbGlicmF0aW9uIGJlbmNobWFy
awojCiMgcmV2ZXJzZS1lbmdpbmVlciB0aGUgYWN0dWFsIHBlci1ieXRlIElQQwojIGNvc3Qg
YnkgdmFyeWluZyB0dXBsZSB3aWR0aCB0aHJvdWdoIGEgR2F0aGVyIG5vZGUgYW5kIG1lYXN1
cmluZyBydW50aW1lLgojCiMgTWV0aG9kb2xvZ3k6CiMgLSBDcmVhdGUgdGFibGVzIHdpdGgg
YW4gaW50ZWdlciBpZCBhbmQgYSBmaXhlZC13aWR0aCB0ZXh0IGNvbHVtbgojIC0gUG9wdWxh
dGUgd2l0aCBscGFkKHZhbCwgVywgJ3gnKSBmb3IgZWFjaCB3aWR0aCBXCiMgLSBSdW46IFNF
TEVDVCB0eHQsIGNvdW50KCopIEZST00gcHRjX2JlbmNoX1cgR1JPVVAgQlkgdHh0CiMgICBU
aGlzIHByb2R1Y2VzIHBhcnRpYWwgYWdncmVnYXRlcyBpbiB3b3JrZXJzLCB0aGVuIEdhdGhl
ciBwYXNzZXMKIyAgICh0eHQsIHBhcnRpYWxfY291bnQpIHR1cGxlcyB3aG9zZSB3aWR0aCDi
iYggVyArIDggYnl0ZXMuCiMgLSBTZXQgd29ya19tZW0gaGlnaCBlbm91Z2ggdGhhdCBwYXJ0
aWFsIGFnZ3JlZ2F0aW9uIHN1Y2NlZWRzIGF0IGFsbCB3aWR0aHMKIyAtIE1lYXN1cmUgcnVu
dGltZSBhdCBlYWNoIHdpZHRoLCBwYXJhbGxlbCBPTiBhbmQgT0ZGLCBiZXN0IG9mIDUKIyAt
IENvbXBhcmUgcHJlZGljdGVkIHZzIGFjdHVhbCBvdmVyaGVhZCBzY2FsaW5nCgpzZXQgLWV1
byBwaXBlZmFpbAoKUEdCSU49L2hvbWUvYW5kcmV3L3BnbC9wdGVzdC9pbnN0L2JpbgpQT1JU
PTU2NzkKREI9cHRjX2NhbGlicmF0ZQpPVVRESVI9L2hvbWUvYW5kcmV3L3BnbC9wdGVzdC9i
ZW5jaC9wdGNfY2FsaWJyYXRlX3Jlc3VsdHMKTlJPV1M9MTAwMDAwMDAgICAgIyAxME0gcm93
cwpORElTVElOQ1Q9MTAwMDAwICAjIDEwMEsgZGlzdGluY3QgdGV4dCB2YWx1ZXMKCm1rZGly
IC1wICIkT1VURElSIgo+ICIkT1VURElSL2FnZ19kZXRhaWwudHh0IgoKcHNxbF9jbWQoKSB7
CiAgICAiJFBHQklOL3BzcWwiIC1oIC90bXAgLXAgJFBPUlQgLWQgIiREQiIgLXFBdCAiJEAi
Cn0KCnBzcWxfY21kX3RpbWluZygpIHsKICAgICIkUEdCSU4vcHNxbCIgLWggL3RtcCAtcCAk
UE9SVCAtZCAiJERCIiAtbyAvZGV2L251bGwgLXFBdCBcCiAgICAgICAgLWMgJ1x0aW1pbmcg
b24nICIkQCIgMj4mMSB8IGdyZXAgLW9QICdUaW1lOiBcS1tcZC5dKycgfCB0YWlsIC0xCn0K
CiMgQ3JlYXRlIHRoZSBkYXRhYmFzZSBpZiBuZWVkZWQKIiRQR0JJTi9wc3FsIiAtaCAvdG1w
IC1wICRQT1JUIC1kIHBvc3RncmVzIC1xQXQgXAogICAgLWMgIlNFTEVDVCAxIEZST00gcGdf
ZGF0YWJhc2UgV0hFUkUgZGF0bmFtZSA9ICckREInIiB8IGdyZXAgLXEgMSBcCiAgICB8fCAi
JFBHQklOL3BzcWwiIC1oIC90bXAgLXAgJFBPUlQgLWQgcG9zdGdyZXMgLXFBdCBcCiAgICAg
ICAgLWMgIkNSRUFURSBEQVRBQkFTRSAkREI7IgoKIyBXaWR0aHM6IHBvd2VycyBvZiAyIHBs
dXMgaW50ZXJtZWRpYXRlIHBvaW50cyB0byBmaWxsIHRoZSA1MTItMTAyNCBnYXAKV0lEVEhT
PSI4IDE2IDMyIDY0IDEyOCAyNTYgMzg0IDUxMiA3NjggMTAyNCIKTldPUktFUlM9MgpOUlVO
Uz01CiMgd29ya19tZW0gbGFyZ2UgZW5vdWdoIGZvciBwYXJ0aWFsIGFnZyBhdCB3aWR0aD0x
MDI0OgojIDEwMEsgZ3JvdXBzIMOXIDEwMjQgYnl0ZXMg4omIIDEwME1CLCBwbHVzIGhhc2gg
b3ZlcmhlYWQg4oaSIHVzZSAyNTZNQgpXT1JLTUVNPSIyNTZNQiIKCmVjaG8gIj09PSBDcmVh
dGluZyBhbmQgcG9wdWxhdGluZyB0YWJsZXMgPT09IgplY2hvICJSb3dzOiAkTlJPV1MsIERp
c3RpbmN0IHZhbHVlczogJE5ESVNUSU5DVCwgd29ya19tZW06ICRXT1JLTUVNIgoKZm9yIFcg
aW4gJFdJRFRIUzsgZG8KICAgICMgUmV1c2UgZXhpc3RpbmcgdGFibGUgaWYgcm93IGNvdW50
IG1hdGNoZXMKICAgIGV4aXN0aW5nPSQocHNxbF9jbWQgLWMgIlNFTEVDVCBjb3VudCgqKSBG
Uk9NIHB0Y19iZW5jaF8ke1d9OyIgMj4vZGV2L251bGwgfHwgZWNobyAiMCIpCiAgICBpZiBb
ICIkZXhpc3RpbmciID0gIiROUk9XUyIgXTsgdGhlbgogICAgICAgIGVjaG8gIiAgd2lkdGg9
JFc6IHJldXNpbmcgZXhpc3RpbmcgdGFibGUgKCRleGlzdGluZyByb3dzKSIKICAgICAgICBj
b250aW51ZQogICAgZmkKICAgIGVjaG8gIiAgTG9hZGluZyB3aWR0aD0kVy4uLiIKICAgIHBz
cWxfY21kIDw8RU9GCkRST1AgVEFCTEUgSUYgRVhJU1RTIHB0Y19iZW5jaF8ke1d9OwpDUkVB
VEUgVEFCTEUgcHRjX2JlbmNoXyR7V30gKAogICAgaWQgIGludGVnZXIgTk9UIE5VTEwsCiAg
ICB0eHQgdGV4dCAgICBOT1QgTlVMTAopOwpJTlNFUlQgSU5UTyBwdGNfYmVuY2hfJHtXfSAo
aWQsIHR4dCkKU0VMRUNUIGcsIGxwYWQoKGcgJSAkTkRJU1RJTkNUKTo6dGV4dCwgJFcsICd4
JykKRlJPTSBnZW5lcmF0ZV9zZXJpZXMoMSwgJE5ST1dTKSBnOwpBTkFMWVpFIHB0Y19iZW5j
aF8ke1d9OwpFT0YKZG9uZQoKZWNobyAiIgplY2hvICI9PT0gVmVyaWZ5aW5nIHRhYmxlIHN0
YXRzID09PSIKZm9yIFcgaW4gJFdJRFRIUzsgZG8KICAgIHBzcWxfY21kIC1jICJTRUxFQ1Qg
JyRXJyBBUyB3aWR0aCwKICAgICAgICBjb3VudCgqKSBBUyByb3dzLAogICAgICAgIGNvdW50
KERJU1RJTkNUIHR4dCkgQVMgZGlzdGluY3RfdmFscywKICAgICAgICBhdmcobGVuZ3RoKHR4
dCkpOjppbnQgQVMgYXZnX2xlbgogICAgICAgIEZST00gcHRjX2JlbmNoXyR7V307Igpkb25l
CgplY2hvICIiCmVjaG8gIj09PSBDb2xsZWN0aW5nIEVYUExBSU4gcGxhbnMgPT09Igpmb3Ig
VyBpbiAkV0lEVEhTOyBkbwogICAgZWNobyAiLS0tIHdpZHRoPSRXIC0tLSIKICAgIHBzcWxf
Y21kIC1jICJTRVQgbWF4X3BhcmFsbGVsX3dvcmtlcnNfcGVyX2dhdGhlciA9ICROV09SS0VS
UzsKICAgICAgICBTRVQgd29ya19tZW0gPSAnJFdPUktNRU0nOwogICAgICAgIEVYUExBSU4g
KFZFUkJPU0UsIENPU1RTIE9OKQogICAgICAgIFNFTEVDVCB0eHQsIGNvdW50KCopIEZST00g
cHRjX2JlbmNoXyR7V30gR1JPVVAgQlkgdHh0OyIgXAogICAgICAgIHwgaGVhZCAtMTUKICAg
IGVjaG8gIiIKZG9uZQoKZWNobyAiIgplY2hvICI9PT0gQmVuY2htYXJrOiBHUk9VUCBCWSB0
eHQsIGNvdW50KCopID09PSIKZWNobyAiICBHYXRoZXIgcGFzc2VzIH4yNDBLLTMwMEsgcGFy
dGlhbCBhZ2dyZWdhdGUgcm93cyBhdCB3aWR0aCDiiYggVyArIDguIgplY2hvICIgIHdvcmtf
bWVtPSRXT1JLTUVNIHRvIGVuc3VyZSBjb25zaXN0ZW50IHBhcnRpYWwgYWdncmVnYXRpb24u
IgplY2hvICIgIEJlc3Qgb2YgJE5SVU5TIHJ1bnMsICROV09SS0VSUyB3b3JrZXJzLiIKZWNo
byAiIgoKQUdHX1FVRVJZX1RFTVBMQVRFPSJTRUxFQ1QgdHh0LCBjb3VudCgqKSBGUk9NIHB0
Y19iZW5jaF9XSURUSCBHUk9VUCBCWSB0eHQiCgpwcmludGYgIiUtOHMgJTEycyAlMTJzICUx
MnMgJTEyc1xuIiAiV2lkdGgiICJQYXJhbGxlbChtcykiICJTZXJpYWwobXMpIiAiU3BlZWR1
cCIgIkdhdGhlciByb3dzIgpwcmludGYgIiUtOHMgJTEycyAlMTJzICUxMnMgJTEyc1xuIiAi
LS0tLS0iICItLS0tLS0tLS0tLS0iICItLS0tLS0tLS0tIiAiLS0tLS0tLSIgIi0tLS0tLS0t
LS0tIgoKZm9yIFcgaW4gJFdJRFRIUzsgZG8KICAgIFE9IiR7QUdHX1FVRVJZX1RFTVBMQVRF
Ly9XSURUSC8kV30iCiAgICBTRVRfQ01EUz0iU0VUIG1heF9wYXJhbGxlbF93b3JrZXJzX3Bl
cl9nYXRoZXIgPSAkTldPUktFUlM7IFNFVCB3b3JrX21lbSA9ICckV09SS01FTSc7IgogICAg
U0VUX1NFUj0iU0VUIG1heF9wYXJhbGxlbF93b3JrZXJzX3Blcl9nYXRoZXIgPSAwOyBTRVQg
d29ya19tZW0gPSAnJFdPUktNRU0nOyIKCiAgICAjIEdldCBHYXRoZXIgcm93IGNvdW50IGZy
b20gRVhQTEFJTgogICAgZ2F0aGVyX3Jvd3M9JChwc3FsX2NtZCAtYyAiJFNFVF9DTURTIEVY
UExBSU4gKENPU1RTIE9OKSAkUTsiIFwKICAgICAgICB8IGdyZXAgLW9QICdHYXRoZXIuKnJv
d3M9XEtcZCsnIHwgaGVhZCAtMSkKICAgIGdhdGhlcl9yb3dzPSR7Z2F0aGVyX3Jvd3M6LSI/
In0KCiAgICAjIFdhcm0gdXAgKDIgcnVucyBlYWNoKQogICAgcHNxbF9jbWQgLWMgIiRTRVRf
Q01EUyAkUSIgPiAvZGV2L251bGwgMj4mMQogICAgcHNxbF9jbWQgLWMgIiRTRVRfQ01EUyAk
USIgPiAvZGV2L251bGwgMj4mMQogICAgcHNxbF9jbWQgLWMgIiRTRVRfU0VSICRRIiA+IC9k
ZXYvbnVsbCAyPiYxCiAgICBwc3FsX2NtZCAtYyAiJFNFVF9TRVIgJFEiID4gL2Rldi9udWxs
IDI+JjEKCiAgICAjIFBhcmFsbGVsIHJ1bnMKICAgIHBhcl90aW1lcz0oKQogICAgZm9yIHIg
aW4gJChzZXEgMSAkTlJVTlMpOyBkbwogICAgICAgIHQ9JChwc3FsX2NtZF90aW1pbmcgXAog
ICAgICAgICAgICAtYyAiU0VUIG1heF9wYXJhbGxlbF93b3JrZXJzX3Blcl9nYXRoZXIgPSAk
TldPUktFUlM7IiBcCiAgICAgICAgICAgIC1jICJTRVQgd29ya19tZW0gPSAnJFdPUktNRU0n
OyIgXAogICAgICAgICAgICAtYyAiJFEiKQogICAgICAgIHBhcl90aW1lcys9KCIkdCIpCiAg
ICBkb25lCgogICAgIyBTZXJpYWwgcnVucwogICAgc2VyX3RpbWVzPSgpCiAgICBmb3IgciBp
biAkKHNlcSAxICROUlVOUyk7IGRvCiAgICAgICAgdD0kKHBzcWxfY21kX3RpbWluZyBcCiAg
ICAgICAgICAgIC1jICJTRVQgbWF4X3BhcmFsbGVsX3dvcmtlcnNfcGVyX2dhdGhlciA9IDA7
IiBcCiAgICAgICAgICAgIC1jICJTRVQgd29ya19tZW0gPSAnJFdPUktNRU0nOyIgXAogICAg
ICAgICAgICAtYyAiJFEiKQogICAgICAgIHNlcl90aW1lcys9KCIkdCIpCiAgICBkb25lCgog
ICAgIyBCZXN0IG9mIE4KICAgIHBhcl9iZXN0PSQocHJpbnRmICclc1xuJyAiJHtwYXJfdGlt
ZXNbQF19IiB8IHNvcnQgLW4gfCBoZWFkIC0xKQogICAgc2VyX2Jlc3Q9JChwcmludGYgJyVz
XG4nICIke3Nlcl90aW1lc1tAXX0iIHwgc29ydCAtbiB8IGhlYWQgLTEpCgogICAgc3BlZWR1
cD0kKHB5dGhvbjMgLWMgInByaW50KGYne2Zsb2F0KFwiJHNlcl9iZXN0XCIpL2Zsb2F0KFwi
JHBhcl9iZXN0XCIpOi4yZn14JykiIDI+L2Rldi9udWxsIHx8IGVjaG8gIj8iKQoKICAgIHBy
aW50ZiAiJS04cyAlMTJzICUxMnMgJTEycyAlMTJzXG4iICIkVyIgIiRwYXJfYmVzdCIgIiRz
ZXJfYmVzdCIgIiRzcGVlZHVwIiAiJGdhdGhlcl9yb3dzIgoKICAgIGVjaG8gIndpZHRoPSRX
IHBhcmFsbGVsOiAke3Bhcl90aW1lc1sqXX0iID4+ICIkT1VURElSL2FnZ19kZXRhaWwudHh0
IgogICAgZWNobyAid2lkdGg9JFcgc2VyaWFsOiAgICR7c2VyX3RpbWVzWypdfSIgPj4gIiRP
VVRESVIvYWdnX2RldGFpbC50eHQiCmRvbmUKCmVjaG8gIiIKZWNobyAiPT09IERvbmU6ICQo
ZGF0ZSAtSXNlY29uZHMpID09PSIK

--------------Hcnbij6pmtNMrGS1Vk5HHQQ5--