MIME-Version: 1.0
From: =?UTF-8?B?0JjQu9GM0Y8g0KHQtdGA0LHQuNC9?= <serbin.ilia@gmail.com>
Date: Mon, 6 Apr 2026 14:34:45 +0400
Message-ID: 
 <CAKS1CiSrRPDcR3YQkf95g-SY6y3TbhO2K4tgdGWbN-YYr0xivg@mail.gmail.com>
Subject: SELECT over partitioned table with LIMIT 1 performance regression
 issue in PostgreSQL 17 and 18
To: pgsql-hackers@postgresql.org
Content-Type: multipart/mixed; boundary="000000000000cf5902064ec83787"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKS1CiSrRPDcR3YQkf95g-SY6y3TbhO2K4tgdGWbN-YYr0xivg%40mail.gmail.com>
Precedence: bulk

--000000000000cf5902064ec83787
Content-Type: multipart/alternative; boundary="000000000000cf5900064ec83785"

--000000000000cf5900064ec83785
Content-Type: text/plain; charset="UTF-8"

Hello,

I think I may have found a planner regression, or at least a planner corner
case, in PostgreSQL 17 and 18 involving a partitioned table, LIMIT 1, and
OR-ed timestamp ranges.

I could not find an existing report that matches this pattern closely, so I
am sending a reproducible example and the observations below to discuss
whether or not this behaviour is appropriate and expected.

Environment
-----------
Observed on:
- PostgreSQL 17.9 on Ubuntu 24.04
- PostgreSQL 15.x and 16.x do not show the same bad parent-level plan for
the same query pattern

Workload pattern
----------------
- A table partitioned by RANGE(ts_col), with weekly partitions
- B-tree indexes on ts_col and kind_col
- ts_col is highly correlated with heap order
- kind_col = 'k_a' is very common (about 81%)
- the query uses LIMIT 1 without ORDER BY
- the filter is:
   kind_col IN (...)
   AND (ts_col in range1 OR ts_col in range2)

Problem summary
---------------
On PostgreSQL 17, the query on the partitioned parent table may choose a
Seq Scan on the child partition instead of a ts_col-based bitmap/index
path, even though the ts_col-based path is much faster when forced.

What looks suspicious to me is this:

1. PostgreSQL 17 can use the ts_col index efficiently for a very similar
query when the OR condition is removed and only one timestamp range is used.
2. PostgreSQL 17 can also execute a forced bitmap path on ts_col very
quickly for the same child partition.
3. But for the parent-table query with OR-ed ranges and LIMIT 1, PostgreSQL
17 may choose a Seq Scan with much worse runtime.

There is also an important difference between PostgreSQL 16 and 17 here:

- On PostgreSQL 16, the child partition by itself may still choose Seq Scan
for this LIMIT 1 pattern, but the query on the partitioned parent chooses a
Bitmap-based Append plan and runs fast.
- On PostgreSQL 17, the parent-level plan no longer does that in this case
and regresses to the poor plan shape.

Representative observations
---------------------------
For the parent query on PostgreSQL 17:

EXPLAIN (ANALYZE, BUFFERS)
SELECT 1
FROM fact_events
WHERE kind_col IN (
   'k_a', 'k_b', 'k_c', 'k_d', 'k_e'
)
AND (
      (ts_col >= '2026-03-28 07:42:30.405987' AND ts_col < '2026-03-28
08:00:00')
   OR (ts_col >= '2026-03-31 12:00:00'        AND ts_col < '2026-03-31
12:10:25.420965')
)
LIMIT 1;

Observed bad plan:
- Seq Scan on the child partition under Append
- runtime around 12 seconds on our production-sized dataset
- Rows Removed by Filter: about 33 million

On the same PostgreSQL 17 instance:

A) Parent query with only one timestamp range:
EXPLAIN (ANALYZE, BUFFERS)
SELECT 1
FROM fact_events
WHERE kind_col IN (
   'k_a', 'k_b', 'k_c', 'k_d', 'k_e'
)
AND ts_col >= '2026-03-28 07:42:30.405987'
AND ts_col <  '2026-03-28 08:00:00'
LIMIT 1;

This uses the ts_col index and returns very quickly.

B) Forced bitmap path on the child partition:
SET enable_seqscan = off;
SET enable_indexscan = off;

EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT 1
FROM fact_events_p2026w13
WHERE kind_col IN (
   'k_a', 'k_b', 'k_c', 'k_d', 'k_e'
)
AND (
      (ts_col >= '2026-03-28 07:42:30.405987' AND ts_col < '2026-03-28
08:00:00')
   OR (ts_col >= '2026-03-31 12:00:00'        AND ts_col < '2026-03-31
12:10:25.420965')
)
LIMIT 1;

This uses BitmapOr + Bitmap Heap Scan via ts_col_idx and also returns
quickly.

C) Default plan for the child partition alone:
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT 1
FROM fact_events_p2026w13
WHERE kind_col IN (
   'k_a', 'k_b', 'k_c', 'k_d', 'k_e'
)
AND (
      (ts_col >= '2026-03-28 07:42:30.405987' AND ts_col < '2026-03-28
08:00:00')
   OR (ts_col >= '2026-03-31 12:00:00'        AND ts_col < '2026-03-31
12:10:25.420965')
)
LIMIT 1;

This can still choose Seq Scan on the child relation itself, but on
PostgreSQL 16 the parent-level Append plan is still good, while on
PostgreSQL 17 the parent-level plan may also fall back to the poor plan
shape.

Why this looks suspicious
-------------------------
- The ts_col-based path is clearly valid and fast.
- This is not just a matter of missing statistics or tuning. I tried
extended statistics, random_page_cost, effective_cache_size, and
combinations of these, and they did not fix the bad parent-level plan.
- I can reproduce the issue not only on a tuned production-like setup, but
also on plain PostgreSQL containers with no special tuning.
- The issue looks related to parent/Append planning for LIMIT 1 on a
partitioned table with OR-ed ranges.
- PostgreSQL 17 release notes mention planner changes in this area: LIMIT
optimization on partitioned tables, inheritance parents, and UNION ALL.
Commit that looks potentially relevant is a8a968a82 (Consider cheap startup
paths in add_paths_to_append_rel, PG17), which introduced startup-path
selection for Append nodes. I have not confirmed this is the root cause,
but the behavior and timing match: if Seq Scan wins as
cheapest_startup_path because BitmapOr has higher startup cost, the
parent-level Append would pick the wrong path for LIMIT queries.

My guess is that the planner is underestimating how bad the Seq Scan really
is for LIMIT 1 in this case. Since ts_col is very highly correlated with
heap order, the matching rows are physically located close to the end of
the partition, so the Seq Scan ends up reading a very large part of the
table before it finds the first match.

Testing
------------
I am attaching two SQL files:
- reproduce_preparation_env.sql
 This file creates the schema, partitions, indexes, and loads the test data.
- reproduce.sql
 This file runs the actual query tests and prints short headings and
comments before each step, so the output is easier to read.

The tests were performed on four clean Docker containers running PostgreSQL
15, 16, 17, 18

Notes
-----
- Exact runtimes will depend on hardware and cache state, but the plan
change itself is reproducible. I'm using SET synchronize_seqscans=off; for
more deterministic behaviour of the tests
- In the attached reproduction scripts, the generated row counts are
already large enough to show the difference.
- In my production case, correlation(ts_col) is about 0.999 and kind_col =
'k_a' is about 81%.

Thanks.

--000000000000cf5900064ec83785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>I think I may have found a planner regressio=
n, or at least a planner corner case, in PostgreSQL 17 and 18 involving a p=
artitioned table, LIMIT 1, and OR-ed timestamp ranges.<br><br>I could not f=
ind an existing report that matches this pattern closely, so I am sending a=
 reproducible example and the observations below to discuss whether or not =
this behaviour=C2=A0is appropriate and expected.<br><br>Environment<br>----=
-------<br>Observed on:<br>- PostgreSQL 17.9 on Ubuntu 24.04<br>- PostgreSQ=
L 15.x and 16.x do not show the same bad parent-level plan for the same que=
ry pattern<br><br>Workload pattern<br>----------------<br>- A table partiti=
oned by RANGE(ts_col), with weekly partitions<br>- B-tree indexes on ts_col=
 and kind_col<br>- ts_col is highly correlated with heap order<br>- kind_co=
l =3D &#39;k_a&#39; is very common (about 81%)<br>- the query uses LIMIT 1 =
without ORDER BY<br>- the filter is:<br>=C2=A0 =C2=A0kind_col IN (...)<br>=
=C2=A0 =C2=A0AND (ts_col in range1 OR ts_col in range2)<br><br>Problem summ=
ary<br>---------------<br>On PostgreSQL 17, the query on the partitioned pa=
rent table may choose a Seq Scan on the child partition instead of a ts_col=
-based bitmap/index path, even though the ts_col-based path is much faster =
when forced.<br><br>What looks suspicious to me is this:<br><br>1. PostgreS=
QL 17 can use the ts_col index efficiently for a very similar query when th=
e OR condition is removed and only one timestamp range is used.<br>2. Postg=
reSQL 17 can also execute a forced bitmap path on ts_col very quickly for t=
he same child partition.<br>3. But for the parent-table query with OR-ed ra=
nges and LIMIT 1, PostgreSQL 17 may choose a Seq Scan with much worse runti=
me.<br><br>There is also an important difference between PostgreSQL 16 and =
17 here:<br><br>- On PostgreSQL 16, the child partition by itself may still=
 choose Seq Scan for this LIMIT 1 pattern, but the query on the partitioned=
 parent chooses a Bitmap-based Append plan and runs fast.<br>- On PostgreSQ=
L 17, the parent-level plan no longer does that in this case and regresses =
to the poor plan shape.<br><br>Representative observations<br>-------------=
--------------<br>For the parent query on PostgreSQL 17:<br><br>EXPLAIN (AN=
ALYZE, BUFFERS)<br>SELECT 1<br>FROM fact_events<br>WHERE kind_col IN (<br>=
=C2=A0 =C2=A0&#39;k_a&#39;, &#39;k_b&#39;, &#39;k_c&#39;, &#39;k_d&#39;, &#=
39;k_e&#39;<br>)<br>AND (<br>=C2=A0 =C2=A0 =C2=A0 (ts_col &gt;=3D &#39;2026=
-03-28 07:42:30.405987&#39; AND ts_col &lt; &#39;2026-03-28 08:00:00&#39;)<=
br>=C2=A0 =C2=A0OR (ts_col &gt;=3D &#39;2026-03-31 12:00:00&#39; =C2=A0 =C2=
=A0 =C2=A0 =C2=A0AND ts_col &lt; &#39;2026-03-31 12:10:25.420965&#39;)<br>)=
<br>LIMIT 1;<br><br>Observed bad plan:<br>- Seq Scan on the child partition=
 under Append<br>- runtime around 12 seconds on our production-sized datase=
t<br>- Rows Removed by Filter: about 33 million<br><br>On the same PostgreS=
QL 17 instance:<br><br>A) Parent query with only one timestamp range:<br>EX=
PLAIN (ANALYZE, BUFFERS)<br>SELECT 1<br>FROM fact_events<br>WHERE kind_col =
IN (<br>=C2=A0 =C2=A0&#39;k_a&#39;, &#39;k_b&#39;, &#39;k_c&#39;, &#39;k_d&=
#39;, &#39;k_e&#39;<br>)<br>AND ts_col &gt;=3D &#39;2026-03-28 07:42:30.405=
987&#39;<br>AND ts_col &lt; =C2=A0&#39;2026-03-28 08:00:00&#39;<br>LIMIT 1;=
<br><br>This uses the ts_col index and returns very quickly.<br><br>B) Forc=
ed bitmap path on the child partition:<br>SET enable_seqscan =3D off;<br>SE=
T enable_indexscan =3D off;<br><br>EXPLAIN (ANALYZE, BUFFERS, SETTINGS)<br>=
SELECT 1<br>FROM fact_events_p2026w13<br>WHERE kind_col IN (<br>=C2=A0 =C2=
=A0&#39;k_a&#39;, &#39;k_b&#39;, &#39;k_c&#39;, &#39;k_d&#39;, &#39;k_e&#39=
;<br>)<br>AND (<br>=C2=A0 =C2=A0 =C2=A0 (ts_col &gt;=3D &#39;2026-03-28 07:=
42:30.405987&#39; AND ts_col &lt; &#39;2026-03-28 08:00:00&#39;)<br>=C2=A0 =
=C2=A0OR (ts_col &gt;=3D &#39;2026-03-31 12:00:00&#39; =C2=A0 =C2=A0 =C2=A0=
 =C2=A0AND ts_col &lt; &#39;2026-03-31 12:10:25.420965&#39;)<br>)<br>LIMIT =
1;<br><br>This uses BitmapOr + Bitmap Heap Scan via ts_col_idx and also ret=
urns quickly.<br><br>C) Default plan for the child partition alone:<br>EXPL=
AIN (ANALYZE, BUFFERS, SETTINGS)<br>SELECT 1<br>FROM fact_events_p2026w13<b=
r>WHERE kind_col IN (<br>=C2=A0 =C2=A0&#39;k_a&#39;, &#39;k_b&#39;, &#39;k_=
c&#39;, &#39;k_d&#39;, &#39;k_e&#39;<br>)<br>AND (<br>=C2=A0 =C2=A0 =C2=A0 =
(ts_col &gt;=3D &#39;2026-03-28 07:42:30.405987&#39; AND ts_col &lt; &#39;2=
026-03-28 08:00:00&#39;)<br>=C2=A0 =C2=A0OR (ts_col &gt;=3D &#39;2026-03-31=
 12:00:00&#39; =C2=A0 =C2=A0 =C2=A0 =C2=A0AND ts_col &lt; &#39;2026-03-31 1=
2:10:25.420965&#39;)<br>)<br>LIMIT 1;<br><br>This can still choose Seq Scan=
 on the child relation itself, but on PostgreSQL 16 the parent-level Append=
 plan is still good, while on PostgreSQL 17 the parent-level plan may also =
fall back to the poor plan shape.<br><br>Why this looks suspicious<br>-----=
--------------------<br>- The ts_col-based path is clearly valid and fast.<=
br>- This is not just a matter of missing statistics or tuning. I tried ext=
ended statistics, random_page_cost, effective_cache_size, and combinations =
of these, and they did not fix the bad parent-level plan.<br>- I can reprod=
uce the issue not only on a tuned production-like setup, but also on plain =
PostgreSQL containers with no special tuning.<br>- The issue looks related =
to parent/Append planning for LIMIT 1 on a partitioned table with OR-ed ran=
ges.<br>- PostgreSQL 17 release notes mention planner changes in this area:=
 LIMIT optimization on partitioned tables, inheritance parents, and UNION A=
LL. Commit that looks potentially relevant is a8a968a82 (Consider cheap sta=
rtup paths in add_paths_to_append_rel, PG17), which introduced startup-path=
 selection for Append nodes. I have not confirmed this is the root cause, b=
ut the behavior and timing match: if Seq Scan wins as cheapest_startup_path=
 because BitmapOr has higher startup cost, the parent-level Append would pi=
ck the wrong path for LIMIT queries.<br><br>My guess is that the planner is=
 underestimating how bad the Seq Scan really is for LIMIT 1 in this case. S=
ince ts_col is very highly correlated with heap order, the matching rows ar=
e physically located close to the end of the partition, so the Seq Scan end=
s up reading a very large part of the table before it finds the first match=
.<br><br>Testing<br>------------<br>I am attaching two SQL files:<br>- repr=
oduce_preparation_env.sql =C2=A0<br>=C2=A0This file creates the schema, par=
titions, indexes, and loads the test data.<br>- reproduce.sql =C2=A0<br>=C2=
=A0This file runs the actual query tests and prints short headings and comm=
ents before each step, so the output is easier to read.<br><br>The tests we=
re performed on four clean Docker containers running PostgreSQL 15, 16, 17,=
 18<br><br>Notes<br>-----<br>- Exact runtimes will depend on hardware and c=
ache state, but the plan change itself is reproducible. I&#39;m using=C2=A0=
SET synchronize_seqscans=3Doff; for more deterministic behaviour of the tes=
ts<br>- In the attached reproduction scripts, the generated row counts are =
already large enough to show the difference.<br>- In my production case, co=
rrelation(ts_col) is about 0.999 and kind_col =3D &#39;k_a&#39; is about 81=
%.<br><br>Thanks.</div>

--000000000000cf5900064ec83785--

--000000000000cf5902064ec83787
Content-Type: application/octet-stream; name="reproduce_preparation_env.sql"
Content-Disposition: attachment; filename="reproduce_preparation_env.sql"
Content-Transfer-Encoding: base64
Content-ID: <f_mnn1qa4z0>
X-Attachment-Id: f_mnn1qa4z0

RFJPUCBUWVBFIElGIEVYSVNUUyBldnRfa2luZCBDQVNDQURFOwpDUkVBVEUgVFlQRSBldnRfa2lu
ZCBBUyBFTlVNICgKICAna19hJywKICAna19mJywKICAna19nJywKICAna19oJywKICAna19pJywK
ICAna19kJywKICAna19jJywKICAna19qJywKICAna19rJywKICAna19sJywKICAna19iJywKICAn
a19lJwopOwoKRFJPUCBUQUJMRSBJRiBFWElTVFMgZmFjdF9ldmVudHMgQ0FTQ0FERTsKCkNSRUFU
RSBUQUJMRSBmYWN0X2V2ZW50cyAoCiAgICBwa19pZCBiaWdpbnQgTk9UIE5VTEwsCiAgICBncnBf
aWQgYmlnaW50IE5PVCBOVUxMLAogICAgcmVmX2lkIGJpZ2ludCBOT1QgTlVMTCwKICAgIHJlZl9r
aW5kIHZhcmNoYXIoMjU1KSBOT1QgTlVMTCwKICAgIG1ldHJpY19hIGJpZ2ludCBOT1QgTlVMTCwK
ICAgIHRzX2NvbCB0aW1lc3RhbXAgd2l0aG91dCB0aW1lIHpvbmUgTk9UIE5VTEwsCiAgICBhdXhf
dHh0IHZhcmNoYXIsCiAgICBtZXRyaWNfYiBiaWdpbnQsCiAgICBraW5kX2NvbCBldnRfa2luZCBO
T1QgTlVMTCwKICAgIG1ldHJpY19jIGJpZ2ludCwKICAgIG1ldHJpY19kIG51bWVyaWMoNTQsMTgp
LAogICAgbWV0cmljX2UgbnVtZXJpYyg1NCwxOCkgREVGQVVMVCAwLAogICAgbWV0cmljX2YgbnVt
ZXJpYyg1NCwxOCksCiAgICBhdXhfdHMgdGltZXN0YW1wKDYpIHdpdGhvdXQgdGltZSB6b25lLAog
ICAgUFJJTUFSWSBLRVkgKHRzX2NvbCwgcGtfaWQpCikgUEFSVElUSU9OIEJZIFJBTkdFICh0c19j
b2wpOwoKQ1JFQVRFIFRBQkxFIGZhY3RfZXZlbnRzX3AyMDI2dzEzClBBUlRJVElPTiBPRiBmYWN0
X2V2ZW50cwpGT1IgVkFMVUVTIEZST00gKCcyMDI2LTAzLTIzIDAwOjAwOjAwJykgVE8gKCcyMDI2
LTAzLTMwIDAwOjAwOjAwJyk7CgpDUkVBVEUgVEFCTEUgZmFjdF9ldmVudHNfcDIwMjZ3MTQKUEFS
VElUSU9OIE9GIGZhY3RfZXZlbnRzCkZPUiBWQUxVRVMgRlJPTSAoJzIwMjYtMDMtMzAgMDA6MDA6
MDAnKSBUTyAoJzIwMjYtMDQtMDYgMDA6MDA6MDAnKTsKCkNSRUFURSBJTkRFWCBmYWN0X2V2ZW50
c19wMjAyNncxM190c19pZHgKICBPTiBmYWN0X2V2ZW50c19wMjAyNncxMyAodHNfY29sKTsKQ1JF
QVRFIElOREVYIGZhY3RfZXZlbnRzX3AyMDI2dzEzX2tpbmRfaWR4CiAgT04gZmFjdF9ldmVudHNf
cDIwMjZ3MTMgKGtpbmRfY29sKTsKCkNSRUFURSBJTkRFWCBmYWN0X2V2ZW50c19wMjAyNncxNF90
c19pZHgKICBPTiBmYWN0X2V2ZW50c19wMjAyNncxNCAodHNfY29sKTsKQ1JFQVRFIElOREVYIGZh
Y3RfZXZlbnRzX3AyMDI2dzE0X2tpbmRfaWR4CiAgT04gZmFjdF9ldmVudHNfcDIwMjZ3MTQgKGtp
bmRfY29sKTsKClNFVCBzeW5jaHJvbm91c19jb21taXQgPSBvZmY7ClNFVCBtYWludGVuYW5jZV93
b3JrX21lbSA9ICcxR0InOwoKV0lUSCBwIEFTICgKICBTRUxFQ1QKICAgIDEyMDAwMDAwOjpiaWdp
bnQgQVMgcDEzX3Jvd3MsCiAgICA2MDAwMDAwOjpiaWdpbnQgIEFTIHAxNF9yb3dzCikKSU5TRVJU
IElOVE8gZmFjdF9ldmVudHMKU0VMRUNUCiAgICBncyBBUyBwa19pZCwKICAgIDEgKyAoZ3MgJSA1
MDAwMDApIEFTIGdycF9pZCwKICAgIGdzIEFTIHJlZl9pZCwKICAgICdSJzo6dmFyY2hhcigyNTUp
IEFTIHJlZl9raW5kLAogICAgMTAwIEFTIG1ldHJpY19hLAogICAgJzIwMjYtMDMtMjMgMDA6MDA6
MDAnOjp0aW1lc3RhbXAKICAgICAgKyAoKGdzIC0gMSk6Om51bWVyaWMgLyAoU0VMRUNUIHAxM19y
b3dzIEZST00gcCkpICogaW50ZXJ2YWwgJzcgZGF5cycKICAgICAgKyAoKGdzICUgMTApICogaW50
ZXJ2YWwgJzEgbWljcm9zZWNvbmQnKSBBUyB0c19jb2wsCiAgICBOVUxMOjp2YXJjaGFyIEFTIGF1
eF90eHQsCiAgICBOVUxMOjpiaWdpbnQgQVMgbWV0cmljX2IsCiAgICBDQVNFCiAgICAgIFdIRU4g
Z3MgJSAxMDAwMDAgPCA4MTE1MCBUSEVOICdrX2EnOjpldnRfa2luZAogICAgICBXSEVOIGdzICUg
MTAwMDAwIDwgOTk1NjMgVEhFTiAna19mJzo6ZXZ0X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAw
MCA8IDk5NzkzIFRIRU4gJ2tfZyc6OmV2dF9raW5kCiAgICAgIFdIRU4gZ3MgJSAxMDAwMDAgPCA5
OTg4MyBUSEVOICdrX2gnOjpldnRfa2luZAogICAgICBXSEVOIGdzICUgMTAwMDAwIDwgOTk5Mjkg
VEhFTiAna19pJzo6ZXZ0X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAwMCA8IDk5OTU2IFRIRU4g
J2tfZCc6OmV2dF9raW5kCiAgICAgIFdIRU4gZ3MgJSAxMDAwMDAgPCA5OTk2NiBUSEVOICdrX2Mn
OjpldnRfa2luZAogICAgICBXSEVOIGdzICUgMTAwMDAwIDwgOTk5NzYgVEhFTiAna19qJzo6ZXZ0
X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAwMCA8IDk5OTg2IFRIRU4gJ2tfayc6OmV2dF9raW5k
CiAgICAgIFdIRU4gZ3MgJSAxMDAwMDAgPCA5OTk5MyBUSEVOICdrX2wnOjpldnRfa2luZAogICAg
ICBXSEVOIGdzICUgMTAwMDAwIDwgMTAwMDAwIFRIRU4gJ2tfYic6OmV2dF9raW5kCiAgICAgIEVM
U0UgJ2tfZSc6OmV2dF9raW5kCiAgICBFTkQgQVMga2luZF9jb2wsCiAgICBOVUxMOjpiaWdpbnQs
CiAgICBOVUxMOjpudW1lcmljKDU0LDE4KSwKICAgIDA6Om51bWVyaWMoNTQsMTgpLAogICAgTlVM
TDo6bnVtZXJpYyg1NCwxOCksCiAgICBOVUxMOjp0aW1lc3RhbXAoNikKRlJPTSBnZW5lcmF0ZV9z
ZXJpZXMoMSwgKFNFTEVDVCBwMTNfcm93cyBGUk9NIHApKSBBUyBnczsKCldJVEggcCBBUyAoCiAg
U0VMRUNUCiAgICAxMjAwMDAwMDo6YmlnaW50IEFTIHAxM19yb3dzLAogICAgNjAwMDAwMDo6Ymln
aW50ICBBUyBwMTRfcm93cwopCklOU0VSVCBJTlRPIGZhY3RfZXZlbnRzClNFTEVDVAogICAgKFNF
TEVDVCBwMTNfcm93cyBGUk9NIHApICsgZ3MgQVMgcGtfaWQsCiAgICAxICsgKGdzICUgNTAwMDAw
KSBBUyBncnBfaWQsCiAgICAoU0VMRUNUIHAxM19yb3dzIEZST00gcCkgKyBncyBBUyByZWZfaWQs
CiAgICAnUic6OnZhcmNoYXIoMjU1KSBBUyByZWZfa2luZCwKICAgIDEwMCBBUyBtZXRyaWNfYSwK
ICAgICcyMDI2LTAzLTMwIDAwOjAwOjAwJzo6dGltZXN0YW1wCiAgICAgICsgKChncyAtIDEpOjpu
dW1lcmljIC8gKFNFTEVDVCBwMTRfcm93cyBGUk9NIHApKSAqIGludGVydmFsICc3IGRheXMnCiAg
ICAgICsgKChncyAlIDEwKSAqIGludGVydmFsICcxIG1pY3Jvc2Vjb25kJykgQVMgdHNfY29sLAog
ICAgTlVMTDo6dmFyY2hhciBBUyBhdXhfdHh0LAogICAgTlVMTDo6YmlnaW50IEFTIG1ldHJpY19i
LAogICAgQ0FTRQogICAgICBXSEVOIGdzICUgMTAwMDAwIDwgODE2ODAgVEhFTiAna19hJzo6ZXZ0
X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAwMCA8IDk5NTQzIFRIRU4gJ2tfZic6OmV2dF9raW5k
CiAgICAgIFdIRU4gZ3MgJSAxMDAwMDAgPCA5OTc2MyBUSEVOICdrX2cnOjpldnRfa2luZAogICAg
ICBXSEVOIGdzICUgMTAwMDAwIDwgOTk4MDkgVEhFTiAna19oJzo6ZXZ0X2tpbmQKICAgICAgV0hF
TiBncyAlIDEwMDAwMCA8IDk5ODc5IFRIRU4gJ2tfaSc6OmV2dF9raW5kCiAgICAgIFdIRU4gZ3Mg
JSAxMDAwMDAgPCA5OTkwNiBUSEVOICdrX2QnOjpldnRfa2luZAogICAgICBXSEVOIGdzICUgMTAw
MDAwIDwgOTk5MTYgVEhFTiAna19jJzo6ZXZ0X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAwMCA8
IDk5OTI2IFRIRU4gJ2tfaic6OmV2dF9raW5kCiAgICAgIFdIRU4gZ3MgJSAxMDAwMDAgPCA5OTkz
NiBUSEVOICdrX2snOjpldnRfa2luZAogICAgICBXSEVOIGdzICUgMTAwMDAwIDwgOTk5NDMgVEhF
TiAna19sJzo6ZXZ0X2tpbmQKICAgICAgV0hFTiBncyAlIDEwMDAwMCA8IDEwMDAwMCBUSEVOICdr
X2InOjpldnRfa2luZAogICAgICBFTFNFICdrX2UnOjpldnRfa2luZAogICAgRU5EIEFTIGtpbmRf
Y29sLAogICAgTlVMTDo6YmlnaW50LAogICAgTlVMTDo6bnVtZXJpYyg1NCwxOCksCiAgICAwOjpu
dW1lcmljKDU0LDE4KSwKICAgIE5VTEw6Om51bWVyaWMoNTQsMTgpLAogICAgTlVMTDo6dGltZXN0
YW1wKDYpCkZST00gZ2VuZXJhdGVfc2VyaWVzKDEsIChTRUxFQ1QgcDE0X3Jvd3MgRlJPTSBwKSkg
QVMgZ3M7CgpWQUNVVU0gKEFOQUxZWkUpIGZhY3RfZXZlbnRzX3AyMDI2dzEzOwpWQUNVVU0gKEFO
QUxZWkUpIGZhY3RfZXZlbnRzX3AyMDI2dzE0OwpBTkFMWVpFIGZhY3RfZXZlbnRzOwoKCg==
--000000000000cf5902064ec83787
Content-Type: application/octet-stream; name="reproduce.sql"
Content-Disposition: attachment; filename="reproduce.sql"
Content-Transfer-Encoding: base64
Content-ID: <f_mnn1qa5a1>
X-Attachment-Id: f_mnn1qa5a1

XHNldCBPTl9FUlJPUl9TVE9QIG9uClx0aW1pbmcgb24KClxlY2hvICcnClxlY2hvICc9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0nClxl
Y2hvICdSRVBSTyBURVNUIFNVSVRFOiBwbGFubmVyIGNob2ljZSBmb3IgcGFydGl0aW9uZWQgdGFi
bGUgKyBMSU1JVCAxJwpcZWNobyAnPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09JwpcZWNobyAnJwoKXGVjaG8gJ1NFVCBzeW5jaHJvbml6
ZV9zZXFzY2Fucz1vZmY7IGZvciBtb3JlIGRldGVybWVuaXN0aWMgYmVoYXZpb3VyJwpTRVQgc3lu
Y2hyb25pemVfc2Vxc2NhbnM9b2ZmOwpzZWxlY3QgdmVyc2lvbigpOwpcZWNobyAnLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJwpcZWNo
byAnVEVTVCAxOiBDaGVjayBjb3JyZWxhdGlvbih0c19jb2wpIG9uIGNoaWxkIHBhcnRpdGlvbnMn
ClxlY2hvICdNZWFuaW5nOiBoaWdoIGNvcnJlbGF0aW9uIG1lYW5zIHRzX2NvbCBpcyBjbG9zZSB0
byBoZWFwIG9yZGVyJwpcZWNobyAnU1FMOicKXGVjaG8gJ1NFTEVDVCB0YWJsZW5hbWUsIGF0dG5h
bWUsIGNvcnJlbGF0aW9uJwpcZWNobyAnRlJPTSBwZ19zdGF0cycKXGVjaG8gJ1dIRVJFIHRhYmxl
bmFtZSBJTiAoJydmYWN0X2V2ZW50c19wMjAyNncxMycnLCAnJ2ZhY3RfZXZlbnRzX3AyMDI2dzE0
JycpJwpcZWNobyAnICBBTkQgYXR0bmFtZSA9ICcndHNfY29sJycnClxlY2hvICdPUkRFUiBCWSB0
YWJsZW5hbWU7JwpcZWNobyAnLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tJwpTRUxFQ1QgdGFibGVuYW1lLCBhdHRuYW1lLCBjb3JyZWxh
dGlvbgpGUk9NIHBnX3N0YXRzCldIRVJFIHRhYmxlbmFtZSBJTiAoJ2ZhY3RfZXZlbnRzX3AyMDI2
dzEzJywgJ2ZhY3RfZXZlbnRzX3AyMDI2dzE0JykKICBBTkQgYXR0bmFtZSA9ICd0c19jb2wnCk9S
REVSIEJZIHRhYmxlbmFtZTsKClxlY2hvICcnClxlY2hvICctLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0nClxlY2hvICdURVNUIDI6IENo
ZWNrIGVzdGltYXRlZCBwYXJ0aXRpb24gc2l6ZXMnClxlY2hvICdNZWFuaW5nOiByZWx0dXBsZXMv
cmVscGFnZXMgaGVscCBleHBsYWluIHBsYW5uZXIgY29zdCBjaG9pY2VzJwpcZWNobyAnU1FMOicK
XGVjaG8gJ1NFTEVDVCByZWxuYW1lLCByZWx0dXBsZXMsIHJlbHBhZ2VzJwpcZWNobyAnRlJPTSBw
Z19jbGFzcycKXGVjaG8gJ1dIRVJFIHJlbG5hbWUgSU4gKCcnZmFjdF9ldmVudHNfcDIwMjZ3MTMn
JywgJydmYWN0X2V2ZW50c19wMjAyNncxNCcnKScKXGVjaG8gJ09SREVSIEJZIHJlbG5hbWU7Jwpc
ZWNobyAnLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tJwpTRUxFQ1QKICAgIHJlbG5hbWUsCiAgICByZWx0dXBsZXMsCiAgICByZWxwYWdl
cwpGUk9NIHBnX2NsYXNzCldIRVJFIHJlbG5hbWUgSU4gKAogICAgJ2ZhY3RfZXZlbnRzX3AyMDI2
dzEzJywKICAgICdmYWN0X2V2ZW50c19wMjAyNncxNCcKKQpPUkRFUiBCWSByZWxuYW1lOwoKXGVj
aG8gJycKXGVjaG8gJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLScKXGVjaG8gJ1RFU1QgMzogUGFyZW50IHF1ZXJ5IHdpdGggT1ItZWQg
dGltZXN0YW1wIHJhbmdlcyBhbmQgTElNSVQgMScKXGVjaG8gJ01lYW5pbmc6IG1haW4gcmVncmVz
c2lvbi9jb3JuZXItY2FzZSBjYW5kaWRhdGUnClxlY2hvICdFeHBlY3RhdGlvbjogUEcxNyBtYXkg
Y2hvb3NlIGEgYmFkIFNlcSBTY2FuIGhlcmUnClxlY2hvICdTUUw6JwpcZWNobyAnRVhQTEFJTiAo
QU5BTFlaRSwgQlVGRkVSUywgU0VUVElOR1MpJwpcZWNobyAnU0VMRUNUIDEnClxlY2hvICdGUk9N
IGZhY3RfZXZlbnRzJwpcZWNobyAnV0hFUkUga2luZF9jb2wgSU4gKCcna19hJycsICcna19iJycs
ICcna19jJycsICcna19kJycsICcna19lJycpJwpcZWNobyAnQU5EICgnClxlY2hvICcgICAgICAg
KHRzX2NvbCA+PSAnJzIwMjYtMDMtMjggMDc6NDI6MzAuNDA1OTg3JycgQU5EIHRzX2NvbCA8ICcn
MjAyNi0wMy0yOCAwODowMDowMCcnKScKXGVjaG8gJyAgICBPUiAodHNfY29sID49ICcnMjAyNi0w
My0zMSAxMjowMDowMCcnICAgICAgICBBTkQgdHNfY29sIDwgJycyMDI2LTAzLTMxIDEyOjEwOjI1
LjQyMDk2NScnKScKXGVjaG8gJyknClxlY2hvICdMSU1JVCAxOycKXGVjaG8gJy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKRVhQTEFJ
TiAoQU5BTFlaRSwgQlVGRkVSUywgU0VUVElOR1MpClNFTEVDVCAxCkZST00gZmFjdF9ldmVudHMK
V0hFUkUga2luZF9jb2wgSU4gKAogICAgJ2tfYScsICdrX2InLCAna19jJywgJ2tfZCcsICdrX2Un
CikKQU5EICgKICAgICAgICh0c19jb2wgPj0gJzIwMjYtMDMtMjggMDc6NDI6MzAuNDA1OTg3JyBB
TkQgdHNfY29sIDwgJzIwMjYtMDMtMjggMDg6MDA6MDAnKQogICAgT1IgKHRzX2NvbCA+PSAnMjAy
Ni0wMy0zMSAxMjowMDowMCcgICAgICAgIEFORCB0c19jb2wgPCAnMjAyNi0wMy0zMSAxMjoxMDoy
NS40MjA5NjUnKQopCkxJTUlUIDE7CgpcZWNobyAnJwpcZWNobyAnLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJwpcZWNobyAnVEVTVCA0
OiBQYXJlbnQgcXVlcnkgd2l0aCBhIHNpbmdsZSB0aW1lc3RhbXAgcmFuZ2UgYW5kIExJTUlUIDEn
ClxlY2hvICdNZWFuaW5nOiBjb250cm9sIGNhc2U7IHBsYW5uZXIgc2hvdWxkIHVzdWFsbHkgdXNl
IHRzX2NvbCBpbmRleCcKXGVjaG8gJ1NRTDonClxlY2hvICdFWFBMQUlOIChBTkFMWVpFLCBCVUZG
RVJTLCBTRVRUSU5HUyknClxlY2hvICdTRUxFQ1QgMScKXGVjaG8gJ0ZST00gZmFjdF9ldmVudHMn
ClxlY2hvICdXSEVSRSBraW5kX2NvbCBJTiAoJydrX2EnJywgJydrX2InJywgJydrX2MnJywgJydr
X2QnJywgJydrX2UnJyknClxlY2hvICdBTkQgdHNfY29sID49ICcnMjAyNi0wMy0yOCAwNzo0Mjoz
MC40MDU5ODcnJycKXGVjaG8gJ0FORCB0c19jb2wgPCAgJycyMDI2LTAzLTI4IDA4OjAwOjAwJycn
ClxlY2hvICdMSU1JVCAxOycKXGVjaG8gJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKRVhQTEFJTiAoQU5BTFlaRSwgQlVGRkVSUywg
U0VUVElOR1MpClNFTEVDVCAxCkZST00gZmFjdF9ldmVudHMKV0hFUkUga2luZF9jb2wgSU4gKAog
ICAgJ2tfYScsICdrX2InLCAna19jJywgJ2tfZCcsICdrX2UnCikKQU5EIHRzX2NvbCA+PSAnMjAy
Ni0wMy0yOCAwNzo0MjozMC40MDU5ODcnCkFORCB0c19jb2wgPCAgJzIwMjYtMDMtMjggMDg6MDA6
MDAnCkxJTUlUIDE7CgpcZWNobyAnJwpcZWNobyAnLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJwpcZWNobyAnVEVTVCA1OiBGb3JjZSBi
aXRtYXAgcGF0aCBvbiBjaGlsZCBwYXJ0aXRpb24nClxlY2hvICdNZWFuaW5nOiBkaXNhYmxlIHNl
cXNjYW4gYW5kIHBsYWluIGluZGV4c2NhbiB0byBmb3JjZSBiaXRtYXAgcGF0aCcKXGVjaG8gJ0V4
cGVjdGF0aW9uOiBwcm92ZXMgdHNfY29sLWJhc2VkIGJpdG1hcCBwYXRoIGlzIHZpYWJsZScKXGVj
aG8gJ1NRTDonClxlY2hvICdTRVQgZW5hYmxlX3NlcXNjYW4gPSBvZmY7JwpcZWNobyAnU0VUIGVu
YWJsZV9pbmRleHNjYW4gPSBvZmY7JwpcZWNobyAnJwpcZWNobyAnRVhQTEFJTiAoQU5BTFlaRSwg
QlVGRkVSUywgU0VUVElOR1MpJwpcZWNobyAnU0VMRUNUIDEnClxlY2hvICdGUk9NIGZhY3RfZXZl
bnRzX3AyMDI2dzEzJwpcZWNobyAnV0hFUkUga2luZF9jb2wgSU4gKCcna19hJycsICcna19iJycs
ICcna19jJycsICcna19kJycsICcna19lJycpJwpcZWNobyAnQU5EICgnClxlY2hvICcgICAgICAg
KHRzX2NvbCA+PSAnJzIwMjYtMDMtMjggMDc6NDI6MzAuNDA1OTg3JycgQU5EIHRzX2NvbCA8ICcn
MjAyNi0wMy0yOCAwODowMDowMCcnKScKXGVjaG8gJyAgICBPUiAodHNfY29sID49ICcnMjAyNi0w
My0zMSAxMjowMDowMCcnICAgICAgICBBTkQgdHNfY29sIDwgJycyMDI2LTAzLTMxIDEyOjEwOjI1
LjQyMDk2NScnKScKXGVjaG8gJyknClxlY2hvICdMSU1JVCAxOycKXGVjaG8gJy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKU0VUIGVu
YWJsZV9zZXFzY2FuID0gb2ZmOwpTRVQgZW5hYmxlX2luZGV4c2NhbiA9IG9mZjsKCkVYUExBSU4g
KEFOQUxZWkUsIEJVRkZFUlMsIFNFVFRJTkdTKQpTRUxFQ1QgMQpGUk9NIGZhY3RfZXZlbnRzX3Ay
MDI2dzEzCldIRVJFIGtpbmRfY29sIElOICgKICAgICdrX2EnLCAna19iJywgJ2tfYycsICdrX2Qn
LCAna19lJwopCkFORCAoCiAgICAgICAodHNfY29sID49ICcyMDI2LTAzLTI4IDA3OjQyOjMwLjQw
NTk4NycgQU5EIHRzX2NvbCA8ICcyMDI2LTAzLTI4IDA4OjAwOjAwJykKICAgIE9SICh0c19jb2wg
Pj0gJzIwMjYtMDMtMzEgMTI6MDA6MDAnICAgICAgICBBTkQgdHNfY29sIDwgJzIwMjYtMDMtMzEg
MTI6MTA6MjUuNDIwOTY1JykKKQpMSU1JVCAxOwoKXGVjaG8gJycKXGVjaG8gJy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKXGVjaG8g
J1RFU1QgNjogUmVzZXQgcGxhbm5lciBHVUNzIGJhY2sgdG8gZGVmYXVsdHMnClxlY2hvICdTUUw6
JwpcZWNobyAnUkVTRVQgZW5hYmxlX3NlcXNjYW47JwpcZWNobyAnUkVTRVQgZW5hYmxlX2luZGV4
c2NhbjsnClxlY2hvICctLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0nClJFU0VUIGVuYWJsZV9zZXFzY2FuOwpSRVNFVCBlbmFibGVfaW5k
ZXhzY2FuOwoKXGVjaG8gJycKXGVjaG8gJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKXGVjaG8gJ1RFU1QgNzogRGVmYXVsdCBjaGls
ZC1wYXJ0aXRpb24gcXVlcnkgd2l0aCBPUi1lZCByYW5nZXMgYW5kIExJTUlUIDEnClxlY2hvICdN
ZWFuaW5nOiBjb21wYXJlIGRlZmF1bHQgY2hpbGQgcGxhbiB2cyBmb3JjZWQgYml0bWFwIHBsYW4n
ClxlY2hvICdTUUw6JwpcZWNobyAnRVhQTEFJTiAoQU5BTFlaRSwgQlVGRkVSUywgU0VUVElOR1Mp
JwpcZWNobyAnU0VMRUNUIDEnClxlY2hvICdGUk9NIGZhY3RfZXZlbnRzX3AyMDI2dzEzJwpcZWNo
byAnV0hFUkUga2luZF9jb2wgSU4gKCcna19hJycsICcna19iJycsICcna19jJycsICcna19kJycs
ICcna19lJycpJwpcZWNobyAnQU5EICgnClxlY2hvICcgICAgICAgKHRzX2NvbCA+PSAnJzIwMjYt
MDMtMjggMDc6NDI6MzAuNDA1OTg3JycgQU5EIHRzX2NvbCA8ICcnMjAyNi0wMy0yOCAwODowMDow
MCcnKScKXGVjaG8gJyAgICBPUiAodHNfY29sID49ICcnMjAyNi0wMy0zMSAxMjowMDowMCcnICAg
ICAgICBBTkQgdHNfY29sIDwgJycyMDI2LTAzLTMxIDEyOjEwOjI1LjQyMDk2NScnKScKXGVjaG8g
JyknClxlY2hvICdMSU1JVCAxOycKXGVjaG8gJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScKRVhQTEFJTiAoQU5BTFlaRSwgQlVGRkVS
UywgU0VUVElOR1MpClNFTEVDVCAxCkZST00gZmFjdF9ldmVudHNfcDIwMjZ3MTMKV0hFUkUga2lu
ZF9jb2wgSU4gKAogICAgJ2tfYScsICdrX2InLCAna19jJywgJ2tfZCcsICdrX2UnCikKQU5EICgK
ICAgICAgICh0c19jb2wgPj0gJzIwMjYtMDMtMjggMDc6NDI6MzAuNDA1OTg3JyBBTkQgdHNfY29s
IDwgJzIwMjYtMDMtMjggMDg6MDA6MDAnKQogICAgT1IgKHRzX2NvbCA+PSAnMjAyNi0wMy0zMSAx
MjowMDowMCcgICAgICAgIEFORCB0c19jb2wgPCAnMjAyNi0wMy0zMSAxMjoxMDoyNS40MjA5NjUn
KQopCkxJTUlUIDE7CgpcZWNobyAnJwpcZWNobyAnPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09JwpcZWNobyAnRU5EIE9GIFJFUFJPIFRF
U1QgU1VJVEUnClxlY2hvICc9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0nClxlY2hvICcn
--000000000000cf5902064ec83787--