Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j8mIH-0001ZS-6N for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:43:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j8mIF-0008VH-VJ for pgsql-interfaces@arkaria.postgresql.org; Mon, 02 Mar 2020 14:43:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j8mIF-0008VA-KA for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:43:39 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j8mID-00069L-1p for pgsql-interfaces@lists.postgresql.org; Mon, 02 Mar 2020 14:43:38 +0000 Received: by mail-wm1-x330.google.com with SMTP id g83so8708262wme.1 for ; Mon, 02 Mar 2020 06:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version; bh=BF7BGhsAXt6+oly9uzWiINesEyT162iKjz6MpCHuavw=; b=fwG6BKD9pFz5nITaoBFGE4/MMs9OF72S7Vki53DquBNyIIH6ePCLsHRKwmpvCq8Pyc KnoisDjeqP1tJWrUzCyJ62VqGlycjEjTVAnIDl6U/RAfsvhqxC9L0rjob7G+jRgYBtVU 3USq8iPnmDZiUgYlDbB4w9mNg7/6atTNBmONUWEv+rAYV9ukr415m1kTJG4UbMgEkv/I XbkzWw+DWaQullC6FuRU7XljO4q9yA4tfUCZE/SvSPvEmP1aA0x1bIWhkHy71KpDuRN+ jKh/j7Ojt4daR9fcOtrZyp4WY44UTKuifqkMx18WkC3p7u/nv/vChV+9zmXAQN/ghixr OHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version; bh=BF7BGhsAXt6+oly9uzWiINesEyT162iKjz6MpCHuavw=; b=GsagWwvYvb/n7EnTUrwIcumoGfcdLZA/Qutk+o3nylv1bI548swwnqFI3Fsr6WXozu 48JzKEF0/FnyR8p9aCxxVHaGjMcqzQ0WwrND/SUbzV+qeatx6ekyVCwkyMWuxy7SRJ3I jgOUh40CHFuDHeFm9k2kaMvPewMhMn2JssYCWVQNTOqaTieRpvxloHwF+PzNW2C35ojv cWy+tV6NyhY17Zxm9xBPngpbxAdeoM8fgK7DEdcOQKUn5TFeEPNlbcwjmmsJdZFwYxGM 7mFZxA0wsht0171CCSyJXHsUmIzfbnalPSAJGTcyFrGoLUnhdN+pB1eDc2sZZN6PTPAQ MWDQ== X-Gm-Message-State: APjAAAW/MKyrezcz3Wm1YmbcZjFkgHx5iYbD/woOk6MxsE7SgThLRM4H ALAkr8krDqJq2TXKgvm8URuUu8r1Shg= X-Google-Smtp-Source: APXvYqws7eYbFYyt3nz/pPte+XTe3o9MdF1qjMPF9chFFq/pQYLRXX1wTIGLWZVqvUsvSdr4uqWtlg== X-Received: by 2002:a1c:80d4:: with SMTP id b203mr20786100wmd.91.1583160215402; Mon, 02 Mar 2020 06:43:35 -0800 (PST) Received: from ?IPv6:2a02:ab04:149:6d00:68a3:e1bb:e30d:4ff8? (2a02-ab04-0149-6d00-68a3-e1bb-e30d-4ff8.dynamic.v6.chello.sk. [2a02:ab04:149:6d00:68a3:e1bb:e30d:4ff8]) by smtp.gmail.com with ESMTPSA id n3sm16176985wmc.42.2020.03.02.06.43.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 06:43:34 -0800 (PST) From: "Pavlo Golub" To: "Stefan Wolf" , pgsql-interfaces@lists.postgresql.org Subject: Re: MS-ACCESS 2010, ODBC 12.01, Out of Memory Date: Mon, 02 Mar 2020 14:43:32 +0000 Message-Id: In-Reply-To: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> References: <000e01d5f0a0$9aeec2f0$d0cc48d0$@zpmt.de> Reply-To: "Pavlo Golub" User-Agent: eM_Client/7.2.37929.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ------ Original Message ------ From: "Stefan Wolf" To: pgsql-interfaces@lists.postgresql.org Sent: 2020-03-02 15:41:05 Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory >Win10-Client: MS-ACCESS 2010 (32-Bit), ODBC-Driver: 12.01 > >Linux-Server (1): PostgreSQL 12.2 > >Linux-Server (2): PostgreSQL 9.6 > > > > > >We are currently migrating from PG 9.6. to 12.x. > > > >We=E2=80=99ve created System-DSNs (PostgreSQL Unicode) with [Defaults] for = both=20 >Server. > > > >In MS-ACCESS our biggest Server-Tables (>14.000.000 Rows) can be opened=20 >(on both Servers). > >But it takes a lot of time and uses a lot of memory - more than 450MBon=20 >the client and some GB on the server. > > > This is for sure MsAcess problem, and not a bug of PostgreSQL. > > >The indexes are recognized an filtering is fast. > > > >Trying to open more than one =E2=80=9Cbig table=E2=80=9D will result in MS= -ACCESS =E2=80=9COut=20 >of memory=E2=80=9D. > Sounds like msAccess fetches all rows and put them into memory which is=20 weird and unwise. Not a bug of PostgreSQL > > > > >Best regards > >-Stefan Wolf- > > > --------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
------ Original Message ------
From: "Stefan Wolf" <sw@zpmt.de&g= t;
Sent: 2020-03-02 15:41:05
Subject: MS-ACCESS 2010, ODBC 12.01, Out of Memory

Win10-Client: =C2=A0MS-ACCESS 2010 (32-Bit),=C2=A0 ODBC-Driver: =C2=A012.= 01

Linux-Server (1):=C2=A0 PostgreSQL 12.2

= Linux-Server (2):=C2=A0 PostgreSQL =C2=A09.6

=C2=A0

=C2=A0

We are currently migrating from PG 9.6. to 12.x.

=C2=A0

We=E2=80=99ve created System-DSNs (PostgreSQL Unicode) with [Def= aults] for both Server.

=C2=A0

In MS-ACCES= S our biggest Server-Tables (>14.000.000 Rows) can be opened (on both Se= rvers).

But it takes a lot of time and uses a lot of memory = - more than 450MB on the client and s= ome GB on the server.


This is for sure MsAcess problem, and not a bug of= PostgreSQL.

=C2=A0

The indexes are recognized an filtering is fast.

=C2=A0

Trying to open more than one =E2=80=9Cbig table=E2=80=9D wi= ll result in MS-ACCESS =E2=80=9COut of memory=E2=80=9D.

=
<= br />
Sounds like msAccess fetches all rows and put them = into memory which is weird and unwise. Not a bug of PostgreSQL


=C2=A0

Best regards

-Ste= fan Wolf-

= =C2=A0

--------=_MB7257EB53-46FE-4049-98CD-E1C48C94769E--