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 1rmu95-00AXvH-Bs for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:30:12 +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 1rmu93-004SiK-Mg for pgsql-odbc@arkaria.postgresql.org; Wed, 20 Mar 2024 11:30:10 +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 1rmu93-004SiC-61 for pgsql-odbc@lists.postgresql.org; Wed, 20 Mar 2024 11:30:09 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rmu8z-005XJp-SV for pgsql-odbc@lists.postgresql.org; Wed, 20 Mar 2024 11:30:08 +0000 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-34175878e3cso1800451f8f.0 for ; Wed, 20 Mar 2024 04:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denodo.com; s=google; t=1710934204; x=1711539004; darn=lists.postgresql.org; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=9/R5UXgwq7omEHEskkf9umlcccE4KvgSK2dWfLOpVNM=; b=iLo5PtCLEh5HIpPdErTEPWGZtVjzn2f/wtYsnxT3HsWvaJYURHY/ZjwZ/a4KE2l9+7 1QFUdl2jvxHqCj9LrHZ024E5xbQl0yFE8vHy1ZdKaCx6UYEdfWEhDnI982cWr1OTm6Uz DOj2T8QBW+6eYMCKktUIx8+RJsT49pRV8Mz20= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710934204; x=1711539004; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=9/R5UXgwq7omEHEskkf9umlcccE4KvgSK2dWfLOpVNM=; b=dzYTCbRWhMtFj41bLf2qKcrLc8VbQu66w4DF1fgV4NJpFgcv+K9Cf+XttbDICBxDM7 JQ4fj6rqFkWGbqmcmuGIOPu1gPRXB1hKqsSGWF9nVqYM2lxaBht40/okanxUhO8mqG5I 8334nT821MJBNtvAphoomjk9YuPXqMriURo0hYlhalLgHd4Ckp4g2C+vEK4LRWA2cohE j2TgpOvn4ztuqtHgwXivOwv3yAb47EUNCESifWMX35WTHrnYAQ1PFQ4VnGnrSI928Pgo BvPpDTZ8xlnLJ5h1+Idd4+WsXKhEcBPThFvlbKUMZRPOyvT6tEHseK4TnuBmkkxX2Sk2 QobA== X-Gm-Message-State: AOJu0YwJG2mlbSNDPqmL1ESgF6A4YGnRVpha8khzbd/L5L8Oo2WxMoqs Tk1F1Ohr1lWShU9jBGzR9pd9igR7amdOEa54JTLUQM8LIQbTYPnmEHyKdm5GkqAFIr3Mc0thHg5 uhRjU/zJLH04TtwNyTqOwe95uPvKr1oYoOxPeqwGDw6DW72JNSNsiIL0q1AZ9hAzqOOv0e2NwuL Fbv+MUqLttCrJEi153DGUZ3GTgNRuA4U7U+sAJUx8BRp1P X-Google-Smtp-Source: AGHT+IHu8tyiE3mGgRfnVgX/xXSg9T5YMANG6CKgZTPfX+AqoHoxaGecSAtSWZ0JXBzaI5n+TQkPIg== X-Received: by 2002:adf:a41d:0:b0:341:957b:aa93 with SMTP id d29-20020adfa41d000000b00341957baa93mr983996wra.0.1710934203666; Wed, 20 Mar 2024 04:30:03 -0700 (PDT) Received: from [192.168.6.75] (29.236.117.91.dynamic.reverse-mundo-r.com. [91.117.236.29]) by smtp.gmail.com with ESMTPSA id f6-20020a5d50c6000000b0033e891d97d6sm14472919wrt.107.2024.03.20.04.30.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Mar 2024 04:30:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------ZWFTo6wo0byXYkN7OolgH1m1" Message-ID: Date: Wed, 20 Mar 2024 12:30:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: PostGres ODBC too slow Content-Language: en-US To: pgsql-odbc@lists.postgresql.org References: From: =?UTF-8?Q?Jacobo_S=C3=A1nchez_L=C3=B3pez?= In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------ZWFTo6wo0byXYkN7OolgH1m1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi     Environment is also important. Are you using connecting through LAN or WAN?     WAN communications  are impacted by the size of the data transmitted (and also for not using the network to receive data while processing previously obtained data). ODBC driver as far as I know does use text data serialization which may be bigger than other pg clients. Not having compression does also affect WAN communications but that is postgres related so other clients would be in the same boat. Best regards Jacobo El 20/03/2024 a las 12:17, Dave Cramer escribió: > 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 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 AM 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 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, > --------------ZWFTo6wo0byXYkN7OolgH1m1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi

    Environment is also important. Are you using connecting through LAN or WAN?

    WAN communications  are impacted by the size of the data transmitted (and also for not using the network to receive data while processing previously obtained data). ODBC driver as far as I know does use text data serialization which may be bigger than other pg clients. Not having compression does also affect WAN communications but that is postgres related so other clients would be in the same boat.

   

Best regards

Jacobo

El 20/03/2024 a las 12:17, Dave Cramer escribió:
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


On Wed, 20 Mar 2024 at 02:08, vedant patel <vedantpatel297@gmail.com> 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 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 AM Dave Cramer <davecramer@postgres.rocks> wrote:
Can you explain where/why you think it is too slow ?

Dave Cramer


On Mon, 18 Mar 2024 at 10:56, vedant patel <vedantpatel297@gmail.com> 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,
--------------ZWFTo6wo0byXYkN7OolgH1m1--