Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d65b7-0004nZ-9W for pgsql-interfaces@arkaria.postgresql.org; Thu, 04 May 2017 01:30:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d65b6-0001pS-2z for pgsql-interfaces@arkaria.postgresql.org; Thu, 04 May 2017 01:30:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d63u0-0008D1-Ka for pgsql-interfaces@postgresql.org; Wed, 03 May 2017 23:41:48 +0000 Received: from mail-by2nam03on0087.outbound.protection.outlook.com ([104.47.42.87] helo=NAM03-BY2-obe.outbound.protection.outlook.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d63to-0001Tm-Ml for pgsql-interfaces@postgresql.org; Wed, 03 May 2017 23:41:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6r4OKrZiUm3ypcBZdpX3VEVun3if7VG3xuVM8VNUP1E=; b=bnENmqHgJx1gWPyyJQW0iE/HqCOGkP/FprzoVSqBYXZ+cKkWTWvwcxDIzKgd4+mWEUbnq+qQEWUikxr8KRLf1CjJBgGIs22+hvGltkdPLb3aZEOf1C0nak4G4UReeblT0/XGhQF8+72ZYaGE007+UE5+CqVd3D4+IpYaDxIiF+I= Received: from CY4PR05MB2791.namprd05.prod.outlook.com (10.169.182.137) by CY4PR05MB2789.namprd05.prod.outlook.com (10.169.182.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 3 May 2017 23:41:33 +0000 Received: from CY4PR05MB2791.namprd05.prod.outlook.com ([10.169.182.137]) by CY4PR05MB2791.namprd05.prod.outlook.com ([10.169.182.137]) with mapi id 15.01.1075.010; Wed, 3 May 2017 23:41:33 +0000 From: Reza Taheri To: "pgsql-interfaces@postgresql.org" Subject: PostgreSQL, and ODBC statement handles Thread-Topic: PostgreSQL, and ODBC statement handles Thread-Index: AdLEZxeSleIUpDLqRC6gMYEem0UkIw== Date: Wed, 3 May 2017 23:41:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: postgresql.org; dkim=none (message not signed) header.d=none;postgresql.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.91.2.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY4PR05MB2789;7:i/XTNXfamGMEACkjDKsErXTVBkXczsXmJAoUuJ6rAwamuXSmHU49MK2nowQJQPJ0JkOYpDT8RA/IFd/pN8bzxZdIMEF4JvGRyBb4w/i/GYJk2mtE3HvZjhgsgn2sp0bE2EInkVHgRUxqy5k18uLRma0QFyl9A6iIQ6FBaaB1P2LcXhTe8tqOBg7jOq0UeKTh/Pq3fHvOccjem/wAxbghEy21ub9I3//eqWfVJmIGUDCIl5QOw0EoM2nI23gVBmfHN+xtcOeBafhujy2l4E597qUywRYQAp2ZTyM6Q2gwukb5YBOLL1ei0+YzL+AZAkKXmOwJIB3v/ilCfWVSNDffEg==;20:OXU8b0F42CjZaK+55Z/hjfArokXWM6PhXeVkTeQTKRo61J8Xg6IqoV/+MHP7dJoBwMbvCFqa2d0OiYXDIZXLT03zRcR+t46Jr4kJcgsv29Z0FiN4wH9Bkbams7AM8HMevpGg2umkEME+XdenGzT3NXrNTDMedQNTDiOkzYkUfyc= x-ms-office365-filtering-correlation-id: 07c32699-10bf-4ad2-8983-08d4927dee8b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:CY4PR05MB2789; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148);SRVR:CY4PR05MB2789;BCL:0;PCL:0;RULEID:;SRVR:CY4PR05MB2789; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39410400002)(39850400002)(39400400002)(39840400002)(39450400003)(66066001)(6306002)(5630700001)(9686003)(5660300001)(99286003)(55016002)(3280700002)(8936002)(3660700001)(2906002)(25786009)(2501003)(6116002)(122556002)(790700001)(53936002)(3846002)(102836003)(86362001)(33656002)(81166006)(8676002)(54356999)(54896002)(38730400002)(110136004)(50986999)(189998001)(77096006)(74316002)(6436002)(7696004)(2900100001)(478600001)(2351001)(5640700003)(6506006)(6916009)(7736002);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR05MB2789;H:CY4PR05MB2791.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB2791D721221B213FFDF133AFDE160CY4PR05MB2791namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 23:41:33.3979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2789 X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-interfaces Precedence: bulk Sender: pgsql-interfaces-owner@postgresql.org --_000_CY4PR05MB2791D721221B213FFDF133AFDE160CY4PR05MB2791namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am running a benchmark (TPCx-V) with a single process on the client syste= m handing all the load. Each connection to the server is in a separate thre= ad with its own connection to PGSQL, and its own connection handle and stat= ement handle. I am facing a contention problem with ODBC on the client sid= e. strace and perf top show we are serializing over what appears to be acce= sses to the ODBC statement handle. Contention goes away if I use multiple p= rocesses instead of multiple threads within a process. I suppose I don't understand the concept of "handles" well, but I am surpri= sed that all the threads get the same connection handle number and the same= statement handle number. Does that mean some data structure is shared betw= een the different threads? Is there a way to force different statement hand= les (or handle numbers???) for different threads within one process? I have= asked this question on the ODBC mailing list, and they suggested it could = be something in the postgresql driver. I can provide detailed performance d= ata, but maybe someone can help me figure out what might be a very basic co= nfiguration or parameter setting problem. I am running the following RPMs o= n RHEL 7.1: postgresql93-9.3.5-2PGDG.rhel7.x86_64 postgresql93-odbc-09.03.0300-1PGDG.rhel7.x86_64 unixODBC-2.3.1-10.el7.x86_64 Thanks, Reza --_000_CY4PR05MB2791D721221B213FFDF133AFDE160CY4PR05MB2791namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am running a benc= hmark (TPCx-V) with a single process on the client system handing all the l= oad. Each connection to the server is in a separate thread with its own con= nection to PGSQL, and its own connection handle and statement handle.  I am facing a contention problem with O= DBC on the client side. strace and perf top show we are serializing over wh= at appears to be accesses to the ODBC statement handle. Contention goes awa= y if I use multiple processes instead of multiple threads within a process.

 

I suppose I donR= 17;t understand the concept of “handles” well, but I am surpris= ed that all the threads get the same connection handle number and the same = statement handle number. Does that mean some data structure is shared between the different threads? Is there a way to force different= statement handles (or handle numbers???) for different threads within one = process? I have asked this question on the ODBC mailing list, and they sugg= ested it could be something in the postgresql driver. I can provide detailed performance data, but maybe some= one can help me figure out what might be a very basic configuration or para= meter setting problem. I am running the following RPMs on RHEL 7.1:

postgresql93-9.3.5-= 2PGDG.rhel7.x86_64

postgresql93-odbc-0= 9.03.0300-1PGDG.rhel7.x86_64

unixODBC-2.3.1-10.e= l7.x86_64

 

Thanks,
Reza

--_000_CY4PR05MB2791D721221B213FFDF133AFDE160CY4PR05MB2791namp_--