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 1rmI3N-0074z4-Cz for pgsql-odbc@arkaria.postgresql.org; Mon, 18 Mar 2024 18:49:45 +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 1rmI3L-0058AM-Ud for pgsql-odbc@arkaria.postgresql.org; Mon, 18 Mar 2024 18:49:44 +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 1rmI3L-0058AD-Ni for pgsql-odbc@lists.postgresql.org; Mon, 18 Mar 2024 18:49:44 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rmI3I-005BrX-HP for pgsql-odbc@postgresql.org; Mon, 18 Mar 2024 18:49:43 +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 2A840201B6 for ; Mon, 18 Mar 2024 14:49:40 -0400 (EDT) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a28a6cef709so708728166b.1 for ; Mon, 18 Mar 2024 11:49:40 -0700 (PDT) X-Gm-Message-State: AOJu0YyQMCHWx97wgqSTMi7I3DstmWfTimmEak8bPyFE3m0ulUaZ/y76 MpTrg8sw7T6x2c1pXjqEF9K5Bn0ZFFFMiDsKm1tvX3FXBR1lTemjUdAunIpr3+tefRkjLDON4il L3zrscADWYdYdU+RMO1bNSuFBQwQ= X-Google-Smtp-Source: AGHT+IEqTHulBbjBsbc4Z9Kr2ywxjXHPPMMHJWGRJq5EirLRrkTYJDEhcONCOGwitgj3QZP+xjknNVq7MbZpbqg2z2U= X-Received: by 2002:a17:906:264c:b0:a46:b8fa:518 with SMTP id i12-20020a170906264c00b00a46b8fa0518mr3370911ejc.22.1710787779006; Mon, 18 Mar 2024 11:49:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Mon, 18 Mar 2024 14:49:21 -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="000000000000daa3ef0613f3d12c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000daa3ef0613f3d12c Content-Type: text/plain; charset="UTF-8" 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 driver > provided by Postgres. Upon investigation, we noticed that switching 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 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, the overall performance > remains a concern. > > Given your extensive experience in this area, I would greatly appreciate > your insights and recommendations on which ODBC driver would be most > suitable for our use case. Any advice or suggestions you could offer would > be immensely helpful in resolving this performance issue. > > Let me know in case of any questions or concerns. > > Thanks, > --000000000000daa3ef0613f3d12c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you explain where/why you think it is too slow ?
<= br clear=3D"all">
Dave Cramer
www.postgres.rock= s


On Mon, 18 Mar 2024 at 10:56, vedant pat= el <vedantpatel297@gmail.com= > wrote:
=
Hello=C2=A0There,

Recently, we've encountered so= me performance issues with the ODBC driver provided by Postgres. Upon inves= tigation, we noticed that switching from the UNICODE to ANSI driver resulte= d in performance improvements for some queries, albeit at the expense of ot= hers.

To delve deeper into this matter, I conducted tests using a Py= thon script with the psycopg2 library, and the results were significantly b= etter. However, to address this issue comprehensively, I've explored al= ternative ODBC drivers available in the market. While some minor improvemen= ts were observed in a few queries with a different driver, the overall perf= ormance remains a concern.

Given your extensive experience in this a= rea, I would greatly appreciate your insights and recommendations on which = ODBC driver would be most suitable for our use case. Any advice or suggesti= ons you could offer would be immensely helpful in resolving this performanc= e issue.

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

Thanks,
--000000000000daa3ef0613f3d12c--