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 1sVlHa-00BVxz-BN for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 05:08:22 +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 1sVlHX-00Expi-HO for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 05:08:19 +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 1sVlHX-00ExpZ-1q for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 05:08:19 +0000 Received: from sonic307-22.consmr.mail.sg3.yahoo.com ([106.10.241.39]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVlHU-000nkC-4P for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 05:08:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721624891; bh=zzO+AI8ntoBMD5sIbHpTRB53JTrlTWUuK9qbJRSxLc0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=NeFo7aHJgmXi9WTXIzhKvH9SKlT+jKrnv+S5PAfampQ/ybcsUl/sQs8AqwIajjgUPDgL8JguDMsagQytzCOwLDLt9CTvHv15BwUpopYiplYgNqp9b/RbFaSxW4Wbj/UpvCWzICTrVIWYBzrR391AumUo0y9hSvwjPJAoV9y2tNkALeD2X9JnxHFqmZ61t2C5CgrxpmWsyG9cx2xuX5liRCfIhYeDwvsfJ2hi1VOby9+gcCSfHLicJKar2TCwpV5lH5HIUXS0DvKDamEVC6mh0SS41XDYpXfJwrqDqGfSNb9dpJANwkhFiuxo0mYYupxYTewwHgNhRopnOLJbuDE1PA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721624891; bh=MUV2d/jPt+Q0Z7AXWFtXCNeOwK0X+8ZXm9CsxOl3jmz=; h=X-Sonic-MF:X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ho150r5nUJEit1ZBn2jzYUmqUv44E0y/NrPd9B0j5zEu5VnlgN2xuPq04Sls4inSHdW7CcKTKNkkIKXQeYHn8/fl4xg14yEToPkmgHI8ZlO2oWQ/NE+agsL6hd8F75wtX0eW9JFYHp1eQoNcTtsSeuBDfQcK/YDjR+dFRW7NTEp6ytPVeIGSFqUskyjAqaSpKIuyxe/FyR1l3BTWF+SgsFV3bZyl0hNCtvJagC9VajsPTe/Bl9J10jtJQtKOkjgJtX0RMt8mGpWXjveLSekyDZ/NRzAQpJlH8OMTK3LyffiDsV8Sx7tjnG7f+P0dH2eeCAg7Mp6writuUKM/RcCg0Q== X-YMail-OSG: ytWT7uwVM1mSJ3rlfjpStXmzeiDCF4Cfvun8C.Of1xCMMN.cGMSVo8ibvV90la4 2gMY5u5hvfq.jfrzj9_EKWZVHsYFwoRnuL9G5DQAl160sHbdrSOFnKT9ZiaIAj8X90d1So3ob.Xi YK6iUsGvJC2HZFtRIIofJku2m_YjgTUPa7tQmhFJONz_RQjmnLCVs5yY7hWrJHpyAMGxIOH6JQwe cAqbLGOEjNFXPuLW4kSaA03aJ1shwww69KZ4C.1_vgOmFZlNhMd6_ksV.9sF2g_38ls9dOXCOOyV dW7YXx89QaywjrSR8ZL1FkHVaGbdeejmBkhZUGCcfv2pkELkVY24zDDSOMKL6zA0C9NTVW2s9AZh K0rr8NyajvQki7tWCr4zvcFvDpeQ3raTfdRlsec.WcquSZYs55z.We0T9T_eWxtMR87Lmyb73ZOL SRLLil2G8wwl6OxlyCHFGOhnpdAkg5.zLmhub09rbqy_DvqisoCLjOLuKpmTNJhBLbpLDCO0tb3C D764hIp2CAr7BIP1_SVbTpQngqfrTBxDPK80Pgyr9Fqg_oSxv53P3qiX.ZI_7fCyU13nro0.E.o0 VBEgYYs17_LNdmoRjhNp1YoadIjnM_SJqbeXMaSm6KB4EgB_g0flgcR3iuMU00A4rLbt2Tg5lcgm 1b.Bc_pWtI.vu7HOsnTJ6ZJgfeFFfpnVjLddG0BFVaEAAjwth7_ZJU1gDa1TSFBTisUfk2ahQ8oJ Ca0OjnUsAbWCbOdFDnztx8QLF0_.CxxBO45kZmknlFd91fibDEEcj7rQZTmOeivQdZxuPrU9Fhxz PFfFugdJmHf3LBJhwqxLEhYGeUBdzKC9bKESzlQ7vwUyj3f6HM2CQqQ2.39AuhHkg1ffhJq3Tozh wX4dKiHxbKrJHhuqji5FqPwcehLGWWxsVPdWmcCFYP4srBt.rpP00r4DaPCsnKzkPC0TR6NhPgL_ GAFCNb2kU_iGIwBkUUAnbo.tyg5bS_fB_akhKMi1kFXzBicyqllbJaguLrJ2L_jBA11BoTIecNRh txpiSGYUMnmkxGRzrnSKD_vZZnl6disSM5XmWx3RaNxLys9nGKLmmOu.AGY8pRiv5O3GSNx9XpsO iLnUT616jRoM6.XLdE3LZ3xztSwmyaX8wLPfvaVr1UXe4Acp.QJrVJD2tM5mpnSx_R3wJcETiukF OWf5PbSOJ0KOlxok0TwxmeUnXlIUeykX1mTNMnDF_DWwiAKs6YKJtC6AO3xhWwITDUn6gYMWPyhg G5o.YWgjrDmPqnmqI4P1zOsBSF6_hwKJb6s2bQCXvG.7bW4RAU.CzUZRl7dXC1wfqNOSc8cgiw9z EJaD2JaI2V0dBCMaSZzpcjon9mj9.5ikx9rLYXuwWyOake0uoDSoky1IOVM13SpwS65t18Iy.QQW kbfIxs4tzyU1ukTNVrUHztlxLl7xf9pCjJHrY42QrOnPkgDVk7Hu_8eZ1VuOLcQFJxIAVwXfB0Gt t2MYRv03TTuAHTtC.VjgPkBc3Lg.TKI1XbpIRIdBj0IkG0UDLiZamDF2coZx9g5z87J7OQk7qBWB 3QT1YiOzfITY99QhS.xuzc_QHsKUdqk8GHvFqk6cbFBL9ICgkW6P9k5C1PdBsSOu2tudSxp1OxNS j9.gI3RnbPxedbyI4rftEOZe5i2GPQut8to__4PFFRNBwtszpI4fsHjXwC9Q2.JEJyNeygZHEd_c fn_KMbePAED.utreCEi1hTgChpOS9SyQfdexfpmNLI14Iifi1o5Q90gS3AZIM6FFFKqG9izPUUst NNKmP24yAj8NbcBxdDN.2QVfh1alNgAvKZq523KqOyg0Dql5eAhy9RdPkI.vmrTTD8hctoB729eR My5xB7ALpljl58_ap4bHNfgeH.kdDVRLhfcOen._EdVTPIgMopinBuz3mJqNkT04PcJ6tsrcQ2f9 9eZdaCXSg7NDeGqcvXlemouuegwpt6T89FH9J2POanmKZobiOaX8DNnzPlwYpHPtaZQkipN2Wkan kYZWFtJ06EG3IiXFPcmHGyvYlFl75.bF5sTdBV7XzjLyExOa4Q6geokZ5xHIjTT5ngV_3p3OrjOU NcUYDmRK0SeywYx8MJnViaSzqgWdMuhobWsbwNvCXtZ5PinkkxxuZC3fL2TZ5bQBvGorNuNNOJ_u LdDJgVCFHmBdljGwT9SeSpFQhfr8yj5RW6mXtgp3wiCr.2wVgDF4RsrjpKTHKW56QvHnCJnB3X1h DDHup8UoQnEuAR3k3Tkkd7D7GGrLAXbOj6hp4WSKJfNCgsqRyS8whJk0U3yyWGuHdwn4YicqO_O_ zBm3nNpBmXEvOZnjN X-Sonic-MF: X-Sonic-ID: 39eb85d8-09d4-49b5-8d37-814823a01447 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.sg3.yahoo.com with HTTP; Mon, 22 Jul 2024 05:08:11 +0000 Received: by hermes--production-gq1-799bb7c8cf-dkgg4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b1a9e16562704de6b3b503b4263dceb; Mon, 22 Jul 2024 05:08:08 +0000 (UTC) X-YMail-OSG: MbcRcgkVM1kuuW1SPmh5At6hFDzvvfmSiAvuv_56cS2VXFPEls9yZPPl4AZfnEd 44Kbnf2KQakKQHUZOfHfeeZD6wfPNu45vbjl3tiioUBLo7dbP_0FpXb_jaPIObn01QypW0STXdNF qQ20FuXuCMeMejGjCnDE_nVTWhKl6ea.GUFqpDApHphvpq9RHCZ.IG33YsYIl7zXG_1DpsNMhM6l sD6WBPiXC86pJLGzlezqPRA2doSJ.YkT2rTP7VyjV73QbV5tBKtiEwIK9frGfC_0bs4iwgZZjxoL MlzkRZHKeC7Myzsq9Gqiox9_I4xrjRfL_wFZPlyTlNDeA4Ac8XyDrZCi3Exj4lEPbf0NXFeFhPvH eIuxuEZ2QEVUpoiDNznyQzim_lKCWHj.R9c3eAXKABG4AakApt13t9llJXd8hEhF26h3ubR8qD_B AnbLxIkuLewgV9euyk36yYzpdRN0EtjiX_9LQJFex7WppJ._IkvDODyeGCvKIZlhxjM_nnLPDuXL H_lVD9pIILajdYYR4UtiqGgIHBhCbcPG.DsOc0FEuNO9.0xmwQrG29Xt6lf1_fVZYCZEMslVm6CD btzPBS80u5I7NW1uNuW1lMMIiFxlO8zv0WNm2cJw94ITIqmLmmghgPZbEF3f2jpfTSBBxPQLqYv9 pT0NOiZZDzR4jOV4UjYlPmSIPjiQvNeSVCP6PWxby09_Xl1Qd6Sft2Ya0Q0bukn.kWclyG2TFPM7 cEGY6roCMTwYjZaEHtW5Q90aPIVcKeUSIlEK2wi8clkd6iTonMpPv.gqjdZVpqpQwak1UCMto9Y. VymerjdxX.mM2OBIEAEIXEgbJd7lfjo6rgdvCIlG_YYdS3CnOWwAahP6UAlhi.jGOq8LT1VDRH0H FCAdPigrlZWcmFTbrqq.jaukf_Fw8qaTdZAn7QjzFuDXCG.RPy0Gmv6ZBWbHqXr2l0ia71Olyqka MmfJWoUdDTn9Fq8Gm37Bn.7FbOg.W.fTzWayccIcmyCVvaDZRGgoLdv0vMpf9K_JXBpLMWtIfNJL .l.diOqFcjwFlDGi24wdvj0P6ENRPBl9nlmH2AgUYiaz6vcZgcd0flfF4jw4cXUP3_bot_oJYbGY h8OUmGLydInQgP6pEEqIQEFRpjOo7Y0tzX82bcIsVOXxeSwz_3nFUlzwkheaoFzeoSxzRGpoiRkS wXalYu09F_3jN31JTBsALdvI.Ap.61dKdVPCQBGLDWdqy1FhqSWhZfMs4qLqawYm9kwqqaQq_0kd RapoS_Cr18T7Ol_iiBzO2JrN718oJnkwhRpei7a0i71ZjXpZ3nya6uLbOGbxjhUrU_xn_aeDifGU gfTVYutFX_CoL9nKYvnDMoQl3v.5hm0ehnmXE0FAy4dlEXGibQUmeyQ_uY76la7Lso7pk9dj9AfX CxHAquEYeUFcjvk388AzKpIdKmuJvkpKChgtOwV1TAEg3eLtz8UNybKLuooapOAKNSeJNpNTu.7K YQYX0W_amNiW42ni1wkRXg6O6u7WnadbhrvKfWyyiLn6ejNbdpDhzCtCD2xwFeYGG3rW0eKewzh_ 4iOsiWo8oVKLdh.KGYGiiavCdXoo2bGD7epDQKYlSwN.Tk4YKyrTdGSawUW0IpB19MoA9W.qGEdA 657K3SfZYANQTOsSXpjYMn.Yh81QlYDTSHWYabzHWYzZg_rC09GWzGPLWX9_uXyOcgJkeVptLX94 3gEkCyiUj_ch.LheRJQuqGgwtxHPqUVgUjWkaGpIetAwvc9pdCoSx3w59vW_nAUr99_ICDgrmaGl F1EFdtqeKiii_0SmNFXYtFSzt3kZ6_ApzPI7T_BTwhEcvYtNKY2GWinGeQ4W2kOGI.AOo.dhA4JW _EEazgxs2VWIHxbKrEsoxgaLBHVOgdqvDEtHDQrs8VgMEKto8tfuM6ind2Xg_fUGBYa5k6OOf.yP kBOGbriNJxp0gDxud0dDRIAEiaKnZuOQQKFKQ_n3y27vdvCLRILOiKdO9P3Hhim7Sjvjwj_.UwpS bVIxbbq2cw0wYORjAyiIRXRArvMiLWvWWG.3RFB3frZRKJzhx1.YDplyolwvWg9VVBxIgbcKQkEF j6Pf4RemThWnYjX3JiJS1Nv5pcZK8kdJVUgkEueUySYWe.Sp__3SgkE55N7nCiCX.0S57qY.3es2 HvwKtR6WgkH4juFGe.H7gRV8fOwYC0ismi4KACELdRznWXoOElNM6FSBgfGELHAfNDE9jT_5wOlq Ddhh0qJn5lBti91JKGLmmB5r_tDGKJo_2Lpu0HAZ.fi.bhF4FXHA72YNxcIDi6MaMRvJb_ilforA B_Av2vjT5gdO_1eVHletbUIzjegoJgEZf2KpVdG9UgNeMY2HBDQrvVE2H7InE8SgfGNGZ.eKlDQY - X-Sonic-MF: X-Sonic-ID: 0a1a5b37-eb2a-40e2-8482-c4558182f277 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Jul 2024 05:08:06 +0000 Date: Mon, 22 Jul 2024 05:08:01 +0000 (UTC) From: "sivapostgres@yahoo.com" Reply-To: "sivapostgres@yahoo.com" To: Francisco Olarte Cc: Postgresql General Group Message-ID: <676910651.2764306.1721624881495@mail.yahoo.com> In-Reply-To: References: <937562047.1752859.1721295502145.ref@mail.yahoo.com> <937562047.1752859.1721295502145@mail.yahoo.com> <680243525.2443164.1721475862129@mail.yahoo.com> Subject: Re: Re. Select with where condition times out MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2764305_1188621059.1721624881493" X-Mailer: WebService/1.1.22501 YMailNorrin Content-Length: 13324 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_2764305_1188621059.1721624881493 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 On Saturday, 20 July, 2024 at 10:55:30 pm IST, Francisco Olarte wrote: =20 =20 Hi: Please, avoid top posting, specially when replying to long mail with various points,m it makes it nearly impossible to track what you are replying to. OK On Sat, 20 Jul 2024 at 13:44, sivapostgres@yahoo.com wrote: > Executed > VACUUM FULL VERBOSE > followed by > REINDEX DATABASE dbname; As it has been already said, vacuum full implies reindex ( it basically copies old table to a new one, including indexes, swaps them, deletes old one ). > It didn't increase the performance, still time out happened.=C2=A0 VACUUM= didn't find any dead rows in that particular table. The no dead rows is the interesting part. Yes no dead rows.=C2=A0=C2=A0 > Yes, the actual query and conditions were not given in my first comment.= =C2=A0 Actually where condition is not on the date field alone and the quer= y with current date is only a sample. Then they are worthless and harmful. Query time problems is normally data and statistics dependent and always query dependent. The query you posted has only two ways to be done, and few ways to be improved. Suggestions for it will probably be harmful for other queries. Actual Query:=C2=A0select source_node_id, create_time from sym_data where t= able_name =3D 'tx_combined_sales_header' and ((event_type =3D 'I' and row_d= ata like '"F92DD7AA237A45D99CA5741DF73EA3D1"%') or (event_type in ('U', 'D'= ) and pk_data like '"F92DD7AA237A45D99CA5741DF73EA3D1"')) and create_time >= =3D '2024-07-18 01:43:32.981' order by create_time desc > What I did, > 1.=C2=A0 Took backup (pg_dump) of the database from the server it's runni= ng.=C2=A0 [ Server config. Xeon Silver 4208, Windows Server 2019 Standard ]= . > 2.=C2=A0 Restored in another desktop system, installing PG 11 afresh. > 3.=C2=A0 Performance was excellent.=C2=A0 Within milliseconds I got the r= esult.=C2=A0 Application was run from the desktop. > 4.=C2=A0 Restored the database in the same server, as another database.= =C2=A0 Improved performance but doesn't match the performance of the deskto= p.=C2=A0 Application run from the server itself. What you did not: - Show your tables and indexes. - Show your real queries. - Tell us what "the application is" ( i.e., "psql", "a java app using JDBC", ... ) > Now server got two databases with exactly the same data.=C2=A0 Old one ta= kes more than 15 minutes; newer one takes few seconds.=C2=A0 Application ru= n from the server and also from clients.=C2=A0 In both conditions, the resu= lt is same. After what has been happening, I have to ask. Do you mean ONE server with two databases, or TWO servers with one database each? Also, what are the especs of the server and the desktops, and the postgres configuration on each? A misconfigured server can easily send query time through the roof ( i.e., DB servers want real RAM, if you configure postgres with too much mem and it swaps you can make a query really slow ) I thought I'm clear. My bad. 2 computers were involved in total.=C2=A0 One Xeon Server with Windows 2019= Standard and other one is Intel i5 based Desktop with Windows 10. I took backup (pg_dump) from windows server machine. And restored in the same server as another database.=C2=A0 Now we have 2 da= tabases with identical data in Windows Server. The actual query (given abov= e) is taking more than 15 min in the original database and takes a second i= n the restored database. Also I restored the database in Desktop machine also, which takes ms only.A= ll PG settings are set at installation, and nothing changed by us.=C2=A0 > What else I need to do to correct this issue? No clue. I have done Vacuum, Re-Index in the original database. No improvement. Anyt= hing else that I can do to make the original database to perform just like = the restored database? > I can easily replace the old database with the backup.=C2=A0 Is that only= option? Ah, one clue. From the info I have in this and previous mails, that is the only option for me. Having more info someone may have ideas, but so far the only thing I have concluded is three databases, fast in server, slow in server and desktop, test only. So my only options are fast server and slow server. So my solution would be=C2=A0 "use fast server". As I said, maybe having more data we could suggest "analyze that table with these parameters", or "make this index" or "rewrite this condition in this way", but this is impossible to do with the data you provided. What else ? Regards. Francisco Olarte. =20 ------=_Part_2764305_1188621059.1721624881493 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=20
=20
On Saturday, 20 July, 2024 at 10:55:30 pm IST, Fran= cisco Olarte <folarte@peoplecall.com> wrote:


=20 =20
Hi:

Please, avoid top posting, specially when replying to long mail withvarious points,m it makes it nearly impossible to track wha= t you are
replying to.

OK


On Sat, = 20 Jul 2024 at 13:44, sivapostgres@yahoo.com
<sivapostgres@yahoo.com> wrote:
=

> Exec= uted
> VACUUM FULL VERBOSE
&= gt; followed by
> REINDEX DATABASE dbname;

As it has been already said, vacuum full implies = reindex ( it
basically copies old table to a new one, inc= luding indexes, swaps
them, deletes old one ).
> It didn't increase the performance, still time out happened.=   VACUUM didn't find any dead rows in that particular table.

The no dead rows is the interesting part.

Yes no d= ead rows.  




> Yes, the actual qu= ery and conditions were not given in my first comment.  Actually where= condition is not on the date field alone and the query with current date i= s only a sample.

Then they are worthle= ss and harmful. Query time problems is normally
data and = statistics dependent and always query dependent.

The query you posted has only two ways to be done, and few ways = to be
improved. Suggestions for it will probably be harmf= ul for other
queries.


Actual Query:
 select source_node_id, create_time from sym_da= ta where table_name =3D 'tx_combined_sales_header' and ((event_type =3D 'I'= and row_data like '"F92DD7AA237A45D99CA5741DF73EA3D1"%') or (event_type in= ('U', 'D') and pk_data like '"F92DD7AA237A45D99CA5741DF73EA3D1"')) and cre= ate_time >=3D '2024-07-18 01:43:32.981' order by create_time desc=


> What I did,
> 1.  Took backup (p= g_dump) of the database from the server it's running.  [ Server confi= g. Xeon Silver 4208, Windows Server 2019 Standard ].
>= 2.  Restored in another desktop system, installing PG 11 afresh.
> 3.  Performance was excellent.  Within millise= conds I got the result.  Application was run from the desktop.
> 4.  Restored the database in the same server, as anoth= er database.  Improved performance but doesn't match the performance o= f the desktop.  Application run from the server itself.

What you did not:
- Show your tabl= es and indexes.
- Show your real queries.
- Tell us what "the application is" ( i.e., "psql", "a java app usingJDBC", ... )

> Now = server got two databases with exactly the same data.  Old one takes m= ore than 15 minutes; newer one takes few seconds.  Application run fro= m the server and also from clients.  In both conditions, the result is= same.

After what has been happening, = I have to ask. Do you mean ONE server
with two databases,= or TWO servers with one database each? Also, what
are th= e especs of the server and the desktops, and the postgres
configuration on each? A misconfigured server can easily send query
time through the roof ( i.e., DB servers want real RAM, if you<= br clear=3D"none">configure postgres with too much mem and it swaps you can= make a query
really slow )


<= div dir=3D"ltr" data-setdir=3D"false">I thought I'm clear. My bad.

2 computers were involved in total.  One Xeon Server with W= indows 2019 Standard and other one is Intel i5 based Desktop with Windows 1= 0.
I took backup (pg_dump) from windows server machine.
And restored = in the same server as another database.  Now we have 2 databases with = identical data in Windows Server. The actual query (given above) is taking = more than 15 min in the original database and takes a second in the restore= d database.

Also I restored the database in Desktop mach= ine also, which takes ms only.
= All PG settings are set at installation, and nothing changed by us. 




> What else I need to do to correct this is= sue?

No clue.

I have= done Vacuum, Re-Index in the original database. No improvement. Anything e= lse that I can do to make the original database to perform just like the re= stored database?


> I can easily replace the old database with the= backup.  Is that only option?

Ah= , one clue. From the info I have in this and previous mails, that is
the only option for me. Having more info someone may have ideas= , but
so far the only thing I have concluded is three dat= abases, fast in
server, slow in server and desktop, test = only. So my only options are
fast server and slow server.= So my solution would be  "use fast
server". As I s= aid, maybe having more data we could suggest "analyze
tha= t table with these parameters", or "make this index" or "rewrite
this condition in this way", but this is impossible to do with th= e
data you provided.

What else ?


Regards.

Francisco Olarte.

------=_Part_2764305_1188621059.1721624881493--