Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxZMV-0005gB-H1 for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 14:00:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dxZMU-0008ES-ER for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 14:00:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dxZMP-00088A-Tc for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 14:00:18 +0000 Received: from mail-io0-x22f.google.com ([2607:f8b0:4001:c06::22f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dxZMJ-0002W2-Lz for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 14:00:17 +0000 Received: by mail-io0-x22f.google.com with SMTP id k101so1639694iod.0 for ; Thu, 28 Sep 2017 07:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OUs6OWL8iN5onp9uzVI9WkKEkjN5gBYUNJMY9KOzGKY=; b=UkKUahIdF1Tp+3hhFEZowUf3ksA5cle1oc2e6VGhOVmJz2mez27tSmjcT9BuFSBVhJ QIQR+yQpmkjDB67D5xL53/xmX3bBD8T9oZ+GNYKrr4UmOwgRcCyKziRYDQm9Vg0OE7RX dK2tYzbdIgUlSWMo4G+BVN2Kfx91nHDG/P7mMnyMc6Tw94rEWjEUCQZp5wOiApqMqApF IIVOgP3IINTyQrGTgNUDBW9L9ccVjGNGM4slcOKH03BgmPxGghiPPutepKx1RlkiYkJk +DfFtQHanz0zeM7cxQPQH9EGaB3vMKZO8uNDuTfo18HQtfj2VY30+WViND+rpRrgc4kw Gz0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OUs6OWL8iN5onp9uzVI9WkKEkjN5gBYUNJMY9KOzGKY=; b=Xuord0Pd4mRaYfzMyBRyDS+yvPnfQ7UdBwdMLklid1wmaUzNImMIC+lBPEkdAAjTEP fpZffuSNovUNRjvT+/VNQYtgrPgSpIPuiEqO221aL3CmxamfTrgO3BaPZczfGflAzKc4 r5mWcRCDDLCtqFaqxalZaSKOYi2OP9Vc0A2neS0yQ8bYNN6rbmyWx0W6TVap8rFl6qQd v1qBLTSuwB5b1YCW/FrDAofSR9mNtqIZlIMhnecie0wyIHnOV3HEh2QD6OUW0x6jMUfi 3IksgQE+A/1NXgQ7ZgfsGOTCD13v4fM/rQxkoCNc0xlmalPXrWPxGF89AroGeKlYhBEo 9ayg== X-Gm-Message-State: AMCzsaUitZOxRgBB5vewjCyhwn8E4GBUFZa2Ri0Ye/NeBn1alldJ+coh yj5YtsATwHa0KoTzB3yn5uYwRFI6qPPQXae6iHs= X-Google-Smtp-Source: AOwi7QDiv5rP76Y9g308LABwHHrOI29KPssA46guLSSKC9eX8RD/Al6sXYDAEvbcuvxhNXj2sTKgNPwhb4w3Rst7Sb0= X-Received: by 10.107.53.89 with SMTP id c86mr7692905ioa.125.1506607209189; Thu, 28 Sep 2017 07:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.57.86 with HTTP; Thu, 28 Sep 2017 06:59:48 -0700 (PDT) In-Reply-To: References: <5F8F324242D0E14B97060D4D32CD0F5C014910CA886C@FRSPX100.fr01.awl.atosorigin.net> From: Dave Cramer Date: Thu, 28 Sep 2017 09:59:48 -0400 X-Google-Sender-Auth: BoLjus6MkGhANqPaJMxx_VkoWy4 Message-ID: Subject: Re: Slow query in JDBC To: Subramaniam C Cc: Pavy Philippe , Julien Rouhaud , "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a1144a396854933055a4053f5" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a1144a396854933055a4053f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What version of the driver are you using? The driver does not automatically use a cursor, but it does use prepared statements which can be slower. Can you provide the query and the jdbc query ? Dave Cramer davec@postgresintl.com www.postgresintl.com On 28 September 2017 at 05:59, Subramaniam C wrote: > First output show the output when the query is executed from sql command > line. The second output show when it is executed from the application. AS > per the output it is clear that the when the query is executed through JD= BC > its not using the index (health_index) instead its doing sequence scan. > Please let us know how this issue can be resolved from JDBC? > > 1.) > > > *Limit (cost=3D510711.53..510711.58 rows=3D20 width=3D72)* > > * -> Sort (cost=3D510711.53..511961.53 rows=3D500000 width=3D72)* > > * Sort Key: health_timeseries_table.health* > > * -> WindowAgg (cost=3D0.98..497406.71 rows=3D500000 width=3D72= )* > > * -> Merge Left Join (cost=3D0.98..491156.71 rows=3D50000= 0 > width=3D64)* > > * Merge Cond: (object_table.uuid =3D > health_timeseries_table.mobid)* > > * -> Unique (cost=3D0.42..57977.00 rows=3D500000 > width=3D64)* > > * -> Index Scan Backward using > object_table_pkey on object_table (cost=3D0.42..56727.00 rows=3D500000 > width=3D64)* > > * Index Cond: (("timestamp" >=3D 0) AND > ("timestamp" <=3D '1505990086834'::bigint))* > > * Filter: (tenantid =3D 'perspica'::text)= * > > * -> Materialize (cost=3D0.56..426235.64 rows=3D555= 26 > width=3D16)* > > * -> Unique (cost=3D0.56..425541.56 rows=3D55= 526 > width=3D24)* > > * -> Index Only Scan > using health_index on health_timeseries_table (cost=3D0.56..421644.56 > rows=3D1558800 width=3D24)* > > * Index Cond: (("timestamp" >=3D > '1505989186834'::bigint) AND ("timestamp" <=3D '1505990086834'::bigint))* > > *LOG: duration: 1971.697 ms* > > > > > > 2.) > > > Limit (cost=3D457629.21..457629.26 rows=3D20 width=3D72) > > -> Sort (cost=3D457629.21..458879.21 rows=3D500000 width=3D72) > > Sort Key: health_timeseries_table.health > > -> WindowAgg (cost=3D367431.49..444324.39 rows=3D500000 width= =3D72) > > -> Merge Left Join (cost=3D367431.49..438074.39 rows=3D50= 0000 > width=3D64) > > Merge Cond: (object_table.uuid =3D > health_timeseries_table.mobid) > > -> Unique (cost=3D0.42..57977.00 rows=3D500000 widt= h=3D64) > > -> Index Scan Backward using object_table_pkey > on object_table (cost=3D0.42..56727.00 rows=3D500000 width=3D64) > > Index Cond: (("timestamp" >=3D '0'::bigin= t) > AND ("timestamp" <=3D '1505990400000'::bigint)) > > Filter: (tenantid =3D 'perspica'::text) > > -> Materialize (cost=3D367431.07..373153.32 rows=3D= 55526 > width=3D16) > > -> Unique (cost=3D367431.07..372459.24 > rows=3D55526 width=3D24) > > -> Sort (cost=3D367431.07..369945.16 > rows=3D1005634 width=3D24) > > Sort Key: > health_timeseries_table.mobid DESC, health_timeseries_table."timestamp" > DESC, health_timeseries_table.health > > -> Seq Scan on > health_timeseries_table (cost=3D0.00..267171.00 rows=3D1005634 width=3D2= 4) > > > Filter: (("timestamp" >=3D > '1505989500000'::bigint) AND ("timestamp" <=3D '1505990400000'::bigint)) > > On Thu, Sep 28, 2017 at 2:56 PM, Pavy Philippe < > Philippe.Pavy@worldline.com> wrote: > >> https://www.postgresql.org/docs/current/static/auto-explain.html >> >> >> -----Message d'origine----- >> De : pgsql-performance-owner@postgresql.org [mailto: >> pgsql-performance-owner@postgresql.org] De la part de Julien Rouhaud >> Envoy=C3=A9 : jeudi 28 septembre 2017 11:21 >> =C3=80 : Subramaniam C >> Cc : pgsql-performance@postgresql.org >> Objet : Re: [PERFORM] Slow query in JDBC >> >> On Thu, Sep 28, 2017 at 10:58 AM, Subramaniam C < >> subramaniam31784@gmail.com> wrote: >> > I configured cursor_tuple_fraction to 1 but still I am facing the same >> > issue. >> >> Can you show explain (analyze, buffers) of the query when run from psql >> and run from application (you can use auto_explain for that if needed, s= ee >> https://www.postgresql.org/docs/current/static/auto-explain.html). >> >> >> -- >> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or= g >> ) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-performance >> >> !!!********************************************************* >> **************************** >> "Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9serv= =C3=A9s =C3=A0 >> l'usage exclusif de ses destinataires. Il peut =C3=A9galement =C3=AAtre = prot=C3=A9g=C3=A9 par >> le secret professionnel. Si vous recevez ce message par erreur, merci d'= en >> avertir imm=C3=A9diatement l'exp=C3=A9diteur et de le d=C3=A9truire. L'i= nt=C3=A9grit=C3=A9 du >> message ne pouvant =C3=AAtre assur=C3=A9e sur Internet, la responsabilit= =C3=A9 de >> Worldline ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de ce mes= sage. Bien >> que les meilleurs efforts soient faits pour maintenir cette transmission >> exempte de tout virus, l'exp=C3=A9diteur ne donne aucune garantie =C3=A0= cet =C3=A9gard et >> sa responsabilit=C3=A9 ne saurait =C3=AAtre recherch=C3=A9e pour tout do= mmage r=C3=A9sultant >> d'un virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Worldline liability >> cannot be triggered for the message content. Although the sender endeavo= urs >> to maintain a computer virus-free network, the sender does not warrant t= hat >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted.!!!" >> > > --001a1144a396854933055a4053f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What version of the driver are you using?

The driver does not automatically use a cursor, but it does use prepared= statements which can be slower.


Ca= n you provide the query and the jdbc query ?


<= /div>


On 28 September 2017 at 05:59, Subramaniam C= <subramaniam31784@gmail.com> wrote:
First output show the output when the query is executed from sql c= ommand line. The second output show when it is executed from the applicatio= n. AS per the output it is clear that the when the query is executed throug= h JDBC its not using the index (health_index) instead its doing sequence sc= an. Please let us know how this issue can be resolved from JDBC?

1.)


<= i>Limit=C2=A0 (cost=3D510711.53..510711.58 rows=3D20 width=3D72)=

=C2=A0 ->=C2=A0= Sort=C2=A0 (cost=3D510711.53..511961.53 rows=3D500000 width=3D72)

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Sort Key: health_timeseries_table.health

<= span class=3D"m_64864064281254455gmail-m_-8660843490239021530gmail-Apple-ta= b-span" style=3D"white-space:pre-wrap"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = ->=C2=A0 WindowAgg=C2=A0 (cost=3D0.98..497406.71 rows=3D500000 width=3D7= 2)

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Merge Left Join= =C2=A0 (cost=3D0.98..491156.71 rows=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Merge Cond: (object_table.uui= d =3D health_timeseries_table.mobid)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D0.42..57977.00 ro= ws=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Index Scan Backward using objec= t_table_pkey on object_table=C2=A0 (cost=3D0.42..56727.00 rows=3D500000 wid= th=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Index Cond: (("timestamp" = >=3D 0) AND ("timestamp" <=3D '1505990086834'::bigi= nt))

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filter: (tenantid =3D 'perspica'= ::text)

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->= =C2=A0 Materialize=C2=A0 (cost=3D0.56..426235.64 rows=3D55526 width=3D16)

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D0.56..425541.56 rows=3D55526 wi= dth=3D24)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Index Only Scan using=C2= =A0health_index=C2=A0on health_timeseries_table=C2=A0 (cost=3D0.56..= 421644.56 rows=3D1558800 width=3D24)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Index Cond: (("timestamp" >=3D '150598918683= 4'::bigint) AND ("timestamp" <=3D '1505990086834':= :bigint))

LOG:=C2=A0 duration: 1971.697 ms





2.)


Li= mit=C2=A0 (cost=3D457629.21..457629.26 rows=3D20 width=3D72)

=C2=A0 ->=C2=A0 Sort=C2=A0 (cost= =3D457629.21..458879.21 rows=3D500000 width=3D72)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sort Key: health_tim= eseries_table.health

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 WindowAgg=C2=A0 (cost=3D367431.49..= 444324.39 rows=3D500000 width=3D72)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 M= erge Left Join=C2=A0 (cost=3D367431.49..438074.39 rows=3D500000 width=3D64)=

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Merge Cond: (object_table.= uuid =3D health_timeseries_table.mobid)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D0.42..57977.00 rows=3D500000= width=3D64)

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ->=C2=A0 Index Scan Backward using object_table_pkey on object_ta= ble=C2=A0 (cost=3D0.42..56727.00 rows=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I= ndex Cond: (("timestamp" >=3D '0'::bigint) AND ("= timestamp" <=3D '1505990400000'::bigint))

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= ilter: (tenantid =3D 'perspica'::text)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Materialize=C2=A0 (cost=3D367431.07..37315= 3.32 rows=3D55526 width=3D16)

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D367431.07..372459= .24 rows=3D55526 width=3D24)

<= /span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Sort=C2=A0 (cost=3D3= 67431.07..369945.16 rows=3D1005634 width=3D24)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Sort Key: health_timeseries_table.mobid DESC, health_timeseries_= table."timestamp" DESC, health_timeseries_table.health

<= span class=3D"m_64864064281254455gmail-m_-8660843490239021530gmail-Apple-ta= b-span" style=3D"white-space:pre-wrap"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Seq Scan on health_timeseries_t= able=C2=A0 (cost=3D0.00..267171.00 rows=3D1005634 width=3D24)


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Filter: (("timestamp" >=3D '150598950000= 0'::bigint) AND ("timestamp" <=3D '1505990400000':= :bigint))


On Thu, Sep 28, 2017 at 2:5= 6 PM, Pavy Philippe <Philippe.Pavy@worldline.com> = wrote:
https://www.postgresql.org/docs/current/static/auto-explain.= html


-----Message d'origine-----
De : pgsql-performance-owner@postgresql.org [mailto:pgsql-perfor= mance-owner@postgresql.org] De la part de Julien Rouhaud
Envoy=C3=A9 : jeudi 28 septembre 2017 11:21
=C3=80 : Subramaniam C
Cc : = pgsql-performance@postgresql.org
Objet : Re: [PERFORM] Slow query in JDBC

On Thu, Sep 28, 2017 at 10:58 AM, Subramaniam C <subramaniam31784@gmail.com>= wrote:
> I configured cursor_tuple_fraction to 1 but still I am facing the same=
> issue.

Can you show explain (analyze, buffers) of the query when run from psql and= run from application (you can use auto_explain for that if needed, see https://www.postgresql.org/docs/cu= rrent/static/auto-explain.html).


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pe= rformance

!!!**************************************************************= ***********************
"Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9se= rv=C3=A9s =C3=A0 l'usage exclusif de ses destinataires. Il peut =C3=A9g= alement =C3=AAtre prot=C3=A9g=C3=A9 par le secret professionnel. Si vous re= cevez ce message par erreur, merci d'en avertir imm=C3=A9diatement l= 9;exp=C3=A9diteur et de le d=C3=A9truire. L'int=C3=A9grit=C3=A9 du mess= age ne pouvant =C3=AAtre assur=C3=A9e sur Internet, la responsabilit=C3=A9 = de Worldline ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de ce mes= sage. Bien que les meilleurs efforts soient faits pour maintenir cette tran= smission exempte de tout virus, l'exp=C3=A9diteur ne donne aucune garan= tie =C3=A0 cet =C3=A9gard et sa responsabilit=C3=A9 ne saurait =C3=AAtre re= cherch=C3=A9e pour tout dommage r=C3=A9sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Worldline liability cannot be tr= iggered for the message content. Although the sender endeavours to maintain= a computer virus-free network, the sender does not warrant that this trans= mission is virus-free and will not be liable for any damages resulting from= any virus transmitted.!!!"


--001a1144a396854933055a4053f5--