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 1rmtyG-00AVtS-BS for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:19:00 +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 1rmtxG-004LIi-5N for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:17:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmtxF-004LIY-TH for pgsql-odbc@lists.postgresql.org; Wed, 20 Mar 2024 11:17:58 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rmtx9-005X6f-2r for pgsql-odbc@postgresql.org; Wed, 20 Mar 2024 11:17:55 +0000 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 60F402015A for ; Wed, 20 Mar 2024 07:17:48 -0400 (EDT) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a46f2c9a7bcso75947166b.3 for ; Wed, 20 Mar 2024 04:17:48 -0700 (PDT) X-Gm-Message-State: AOJu0YxwOwLKuGYC33ugTN7w0Jvm3yG0UGiAHzAseN8BrjmoOp5bAjCW JBTa2ZTKnXUA6x/L4QXwYq5oe2dRbq2RaUdZSwNhMA1snJykZ6WdDpzf1Bk9gCzwiuuQYMeqlNp Usb2X5YMWDEGFX6EP3CK6j1XWepE= X-Google-Smtp-Source: AGHT+IEkerhp3jSUg8FJ3pARGR2M71KsaqAvFsO5mzYtXugi0LbwrFBOIC1y56MK5UDg3laciYXj9y+Crwsa3lYraHE= X-Received: by 2002:a17:906:ca03:b0:a46:f279:8f69 with SMTP id jt3-20020a170906ca0300b00a46f2798f69mr1155117ejb.54.1710933467012; Wed, 20 Mar 2024 04:17:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Wed, 20 Mar 2024 07:17:29 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: PostGres ODBC too slow To: vedant patel Cc: pgsql-odbc@postgresql.org Content-Type: multipart/alternative; boundary="000000000000893265061415bd92" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000893265061415bd92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Vedant, Can you share the SQL that is slow. We can't fix this if we don't have a specific problem to look at. Dave Cramer www.postgres.rocks On Wed, 20 Mar 2024 at 02:08, vedant patel wrote= : > Hello Dave, > > We have tried the retrieval using python library psycopg2 and found that > it is taking less amount of time for retrieval. And when we create odbc a= nd > use pyodbc it is taking a large amount of time for that odbc. Along with > that our main application is in PowerBuilder and we need to use ODBC for > that one. We checked the ODBC driver with PowerBuilder and it is taking t= oo > much time. > > Thanks, > > On Tue, Mar 19, 2024 at 12:19=E2=80=AFAM Dave Cramer > wrote: > >> Can you explain where/why you think it is too slow ? >> >> Dave Cramer >> www.postgres.rocks >> >> >> On Mon, 18 Mar 2024 at 10:56, vedant patel >> wrote: >> >>> Hello There, >>> >>> Recently, we've encountered some performance issues with the ODBC drive= r >>> provided by Postgres. Upon investigation, we noticed that switching fro= m >>> the UNICODE to ANSI driver resulted in performance improvements for som= e >>> queries, albeit at the expense of others. >>> >>> To delve deeper into this matter, I conducted tests using a Python >>> script with the psycopg2 library, and the results were significantly >>> better. However, to address this issue comprehensively, I've explored >>> alternative ODBC drivers available in the market. While some minor >>> improvements were observed in a few queries with a different driver, th= e >>> overall performance remains a concern. >>> >>> Given your extensive experience in this area, I would greatly appreciat= e >>> your insights and recommendations on which ODBC driver would be most >>> suitable for our use case. Any advice or suggestions you could offer wo= uld >>> be immensely helpful in resolving this performance issue. >>> >>> Let me know in case of any questions or concerns. >>> >>> Thanks, >>> >> --000000000000893265061415bd92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Vedant,

Can you share the SQL that i= s slow.=C2=A0We can't fix this if we don't have a specific problem = to look at.

Dave Crame= r
www.postgres.rocks


On Wed, 20 Mar 20= 24 at 02:08, vedant patel <v= edantpatel297@gmail.com> wrote:
Hello Dave,

We have tried the retrieval using python lib= rary psycopg2 and found that it is taking less amount of time for retrieval= . And when we create odbc and use pyodbc it is taking a large amount of tim= e for that odbc. Along with that our main application is in PowerBuilder an= d we need to use ODBC for that one. We checked the ODBC driver with=20 PowerBuilder and it is taking too much time.

Thanks,

On Tue, Mar 19, 2024= at 12:19=E2=80=AFAM Dave Cramer <davecramer@postgres.rocks> wrote:
= Can you explain where/why you think it is too slow ?

=
Dave Crame= r
www.postgres.rocks


On Mon, 18 Mar 20= 24 at 10:56, vedant patel <vedantpatel297@gmail.com> wrote:
Hello=C2=A0There,

Recently, we've encountered some performance issues with the ODB= C driver provided by Postgres. Upon investigation, we noticed that switchin= g from the UNICODE to ANSI driver resulted in performance improvements for = some queries, albeit at the expense of others.

To delve deeper into = this matter, I conducted tests using a Python script with the psycopg2 libr= ary, and the results were significantly better. However, to address this is= sue comprehensively, I've explored alternative ODBC drivers available i= n the market. While some minor improvements were observed in a few queries = with a different driver, the overall performance remains a concern.

= Given your extensive experience in this area, I would greatly appreciate yo= ur insights and recommendations on which ODBC driver would be most suitable= for our use case. Any advice or suggestions you could offer would be immen= sely helpful in resolving this performance issue.

Let= me know in case of any questions or concerns.=C2=A0

Thanks,
--000000000000893265061415bd92--