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 1rmuLA-00AYvM-2V for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:42:40 +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 1rmuL8-004VVP-At for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:42:38 +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 1rmos3-002kEW-RF for pgsql-odbc@lists.postgresql.org; Wed, 20 Mar 2024 05:52:16 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rmos1-005Uhc-Pq for pgsql-odbc@postgresql.org; Wed, 20 Mar 2024 05:52:15 +0000 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-29ddfd859eeso4957208a91.1 for ; Tue, 19 Mar 2024 22:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710913932; x=1711518732; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IKxVFHE0rPYUR77gB7HnXx/G3ckCxFPUTIbs5ptKdQk=; b=iaiD95iR7QFr3zTPQL0yAEBnv+mU0Uz7Fxf/HpWw+a6BXAKh06T8G3okr4R7IfEyRF EwXJIdTrxBMbuX9SWi97QPqR2tGhQil7vBDV1EstY8eTZ1HiUo3U8IRZygJj7IymOYCD hEbnVhUcnQruJ+2LRDnKmd1nLfwx/lEZdVTve2lCb8ZYxZzS5C22fcUxS9VkDePzmOQT Rnh1kiNkXU9OSJpZwdWzXh8TMcZ26yqhOLpXHMozY33wteFjObSwOiVxcf8EanO9jdB5 Hu2iqbwvD7lpevj9kdFvygzjzDYJMGAWPY+1pYo+8z41nv38S2mYG9001lh72TGcgWxn fp+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710913932; x=1711518732; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IKxVFHE0rPYUR77gB7HnXx/G3ckCxFPUTIbs5ptKdQk=; b=tOiTYRBVEof+xuH56SR0z1YYzdVU123MC5XEWCtRJE1cybxxOpaLvQg5JBWeNJtz7Y qABAE/mm53d11ebk/q7aTdrgWw1SfkG0d4wjvS3hrEi3AUGIfmZ3ToBRWK0IwsqEi31B ogzhp9KTJ/jqiJdCHjE85RqgCyQuH03uQV10liPfSW3tN9ctDS12KHOJiXbVFkicEGVS yl9O5pBnKDJJnVklfBg7R5cFLfCinC4mKcJa2Mtgl7+cMG7OSNnsWo+kGHgY8UrY052P TWvpmAp3g7z+nKKu7eLMRmAYK4RCrmgT5uMmwdtOKV0ah5QSoHYwMn4lZLT+kCkr0LTk NjzQ== X-Gm-Message-State: AOJu0YxHDG2W8fG0BNjA0zafLIC5T1wEA1kDlGt5VAd6wjsFmzVyaQd8 sm1efWoa0ziUEJ2LoH2yNgN/SCOW2OVCZ7CV5I0u4rxBXcgaVoJMwJODrX9+5r+Si60CS0zaaCR zTLSscQe0SJCIVxJmtoU0/7sP1fg= X-Google-Smtp-Source: AGHT+IEsB+yIMdHwmONZiUcHYG2oBiPiinPX9D7hFeRdqryeCoyGvJp3HlY1HAZslCsc9P6t0yyWmL8m5nqSzcTwLGM= X-Received: by 2002:a17:90a:bd09:b0:29b:c4b7:3300 with SMTP id y9-20020a17090abd0900b0029bc4b73300mr1027415pjr.44.1710913931886; Tue, 19 Mar 2024 22:52:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vedant patel Date: Wed, 20 Mar 2024 11:22:00 +0530 Message-ID: Subject: Re: PostGres ODBC too slow To: Dave Cramer Cc: pgsql-odbc@postgresql.org Content-Type: multipart/alternative; boundary="00000000000026c6f106141131f0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000026c6f106141131f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 and 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 too 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 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 scrip= t >> with the psycopg2 library, and the results were significantly better. >> However, to address this issue comprehensively, I've explored alternativ= e >> ODBC drivers available in the market. While some minor improvements were >> observed in a few queries with a different driver, the overall performan= ce >> 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 wou= ld >> be immensely helpful in resolving this performance issue. >> >> Let me know in case of any questions or concerns. >> >> Thanks, >> > --00000000000026c6f106141131f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dave,

We have tried the retrieval using python library psycopg2 and found t= hat it is taking less amount of time for retrieval. And when we create odbc= and use pyodbc it is taking a large amount of time for that odbc. Along wi= th that our main application is in PowerBuilder and 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,
--00000000000026c6f106141131f0--