Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCnZb-0001Ln-Td for pgsql-performance@arkaria.postgresql.org; Thu, 09 Nov 2017 14:12:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eCnZb-0001GR-Es for pgsql-performance@arkaria.postgresql.org; Thu, 09 Nov 2017 14:12:51 +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 1eBneT-0001C2-K3 for pgsql-performance@postgresql.org; Mon, 06 Nov 2017 20:05:45 +0000 Received: from mail.index.de ([213.160.90.22]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eBneQ-0006ag-1A for pgsql-performance@postgresql.org; Mon, 06 Nov 2017 20:05:44 +0000 Received: from localhost (mail1.index.de [127.0.0.1]) by mail.index.de (Postfix) with ESMTP id 74C3D442064 for ; Mon, 6 Nov 2017 21:05:39 +0100 (CET) Received: from mail.index.de ([127.0.0.1]) by localhost (mail.index.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d-CN3ujqKPjt for ; Mon, 6 Nov 2017 21:05:39 +0100 (CET) Received: from remote.index.de (unknown [217.199.72.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.index.de (Postfix) with ESMTPSA id 44968441EFA for ; Mon, 6 Nov 2017 21:05:39 +0100 (CET) Received: from acedia.index-gruppe.local (192.168.3.121) by acedia.index-gruppe.local (192.168.3.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Mon, 6 Nov 2017 21:05:36 +0100 Received: from acedia.index-gruppe.local ([fe80::ecd1:5d0a:a834:dd56]) by acedia.index-gruppe.local ([fe80::ecd1:5d0a:a834:dd56%2]) with mapi id 15.01.1034.032; Mon, 6 Nov 2017 21:05:36 +0100 From: Arne Roland To: "pgsql-performance@postgresql.org" Subject: Dynamic performance issues Thread-Topic: Dynamic performance issues Thread-Index: AdNXLX4vqPYYpmuGTYiJaE3OgOSJpQAA12IwAAHCViA= Date: Mon, 6 Nov 2017 20:05:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.146] Content-Type: multipart/mixed; boundary="_004_d93e3d0527514efc94975dceaf71442eindexde_" MIME-Version: 1.0 List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --_004_d93e3d0527514efc94975dceaf71442eindexde_ Content-Type: multipart/alternative; boundary="_000_d93e3d0527514efc94975dceaf71442eindexde_" --_000_d93e3d0527514efc94975dceaf71442eindexde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I was encouraged to write up a few simplified, reproducible performance cas= es, that occur (similarly) in our production environment. Attached you find= a generic script that sets up generic tables, used for the three different= cases. While I think at all of them I included the times needed on my machine, the times differ by a small marg= in on rerun. Every block used was hit in the ring buffer, no need to turn t= o the kernel buffer in these cases. While this isn't exactly to be expected= in the production cases, I doubt this impacts the performance-difference t= oo much. Even though I originally developed these examples with different planer set= tings the default ones seem to work quite reasonably. One thing to notice is that in our environment there is a lot of dynamic qu= ery-building going on, which might help understanding why we care about the= second and third case. The first case is the most easy to work around, but I think it's a very com= mon one. While it's true that this is a special case of the - probably not so easy t= o solve - cross table correlation issue, this is somehow special because on= e of the table is accessed via a single unique key. I thought to bring it u= p, since I maintain (meta-)functions that build functions that select and r= einsert these values in the query to expose them to the planner. While this= solution works fine, this is a very common cross table correlation issues = , while another chunk is the case where are referenced by a foreign key. I'= m not sure whether it's a good idea to acquire a lock at planning time or r= ather recheck the exact values at execution time, but even if it's just usi= ng the exact values of that single row (similar to a stable function) at pl= anning time to get a better estimate seems worth it to me. The second case is something that happens a lot in our environment (mainly = in dynamically composed queries). I wouldn't be so pedantic if 30 would be = the largest occurring list length, but we have bigger lists the issue gets = bigger. Besides the constraint exclusion with the values approach I showed, there i= s the much bigger issue artificially introducing cross table correlation is= sues, leading to absurd estimates (just try inserting 100000 in the values = list to see what I mean), damaging the plan if one join more tables to it. = I didn't choose that case even though I think it's much more frequent, just= because joining more relations make it harder to grasp. I try to guess the selectivity of that clause in application code and choos= ing an in or values clause accordingly. As one would expect that is not onl= y annoying to maintain, but in a world of dynamic queries this also leads t= o quite bizarre performance behavior in some cases. Using a hashtable to enforce the predicate (if the list contains more than = x elements) would sound reasonable to me. One might consider workmem, even = though just the thought of having a query string that rivals the size of wo= rk_mem sounds stupid. What do you think? The third case is something a little bit more sophisticated. Sadly it isn't= just tied to this obvious case where one can just create an index (create = unique index on u (expensive_func(id)); would solve this case), but appears= mainly when there are more than three tables with a lot of different predi= cates of different expense and selectivity. Even though it's not that incre= dible frequent, maintaining the corresponding application code (see case tw= o) is still quite painful. Best regards Arne --_000_d93e3d0527514efc94975dceaf71442eindexde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I was encouraged to write up a = few simplified, reproducible performance cases, that occur (similarly) in o= ur production environment. Attached you find a generic script that sets up = generic tables, used for the three different cases. While I think at all of them

I included the times needed on = my machine, the times differ by a small margin on rerun. Every block used w= as hit in the ring buffer, no need to turn to the kernel buffer in these ca= ses. While this isn’t exactly to be expected in the production cases, I doubt this impacts the performance-dif= ference too much.

Even though I originally develo= ped these examples with different planer settings the default ones seem to = work quite reasonably.

 

One thing to notice is that in = our environment there is a lot of dynamic query-building going on, which mi= ght help understanding why we care about the second and third case.

 

The first case is the most easy= to work around, but I think it’s a very common one.

While it’s true that this= is a special case of the – probably not so easy to solve - cross tab= le correlation issue, this is somehow special because one of the table is a= ccessed via a single unique key. I thought to bring it up, since I maintain (meta-)functions that build functions that select = and reinsert these values in the query to expose them to the planner. While= this solution works fine, this is a very common cross table correlation is= sues , while another chunk is the case where are referenced by a foreign key. I’m not sure whether it&= #8217;s a good idea to acquire a lock at planning time or rather recheck th= e exact values at execution time, but even if it’s just using the exa= ct values of that single row (similar to a stable function) at planning time to get a better estimate seems worth it to me.<= o:p>

 

The second case is something th= at happens a lot in our environment (mainly in dynamically composed queries= ). I wouldn’t be so pedantic if 30 would be the largest occurring lis= t length, but we have bigger lists the issue gets bigger.

Besides the constraint exclusio= n with the values approach I showed, there is the much bigger issue artific= ially introducing cross table correlation issues, leading to absurd estimat= es (just try inserting 100000 in the values list to see what I mean), damaging the plan if one join more tables= to it. I didn’t choose that case even though I think it’s much= more frequent, just because joining more relations make it harder to grasp= .

I try to guess the selectivity = of that clause in application code and choosing an in or values clause acco= rdingly. As one would expect that is not only annoying to maintain, but in = a world of dynamic queries this also leads to quite bizarre performance behavior in some cases.

Using a hashtable to enforce th= e predicate (if the list contains more than x elements) would sound reasona= ble to me. One might consider workmem, even though just the thought of havi= ng a query string that rivals the size of work_mem sounds stupid. What do you think?

 

The third case is something a l= ittle bit more sophisticated. Sadly it isn’t just tied to this obviou= s case where one can just create an index (create unique index on u (expens= ive_func(id)); would solve this case), but appears mainly when there are more than three tables with a lot of differe= nt predicates of different expense and selectivity. Even though it’s = not that incredible frequent, maintaining the corresponding application cod= e (see case two) is still quite painful.

 

Best regards<= /p>

Arne

--_000_d93e3d0527514efc94975dceaf71442eindexde_-- --_004_d93e3d0527514efc94975dceaf71442eindexde_ Content-Type: application/octet-stream; name="performance_cases.sql" Content-Description: performance_cases.sql Content-Disposition: attachment; filename="performance_cases.sql"; size=4725; creation-date="Mon, 06 Nov 2017 17:55:09 GMT"; modification-date="Mon, 06 Nov 2017 17:54:50 GMT" Content-Transfer-Encoding: base64 77u/LS1Gb3IgdGhlIGZ1cnRoZXIgdXNlIHRoaXMgZnVuY3Rpb24gd2lsbCBq dXN0IHNlcnZlIGFuIGV4YW1wbGUgZm9yIGFuIGV4cGVuc2l2ZSBvcGVyYXRp b24uIEl0IGlzIG5vdCBpbXBvcnRhbnQgYXQgYWxsIHRoYXQgaXQncyBhIGZ1 bmN0aW9uLCBpdCBqdXN0IG1ha2VzIHRoaW5ncyBtb3JlIHJlYWRhYmxlLg0K LS1XZSBvYnZpb3VzbHkgZG9uJ3QgdXNlIHRoYXQgcGFydGljdWxhciBmdW5j dGlvbiwgYnV0IHRoZSBwcm9qZWN0IEkgZXh0cmFjdGVkIHRoaXMgZXhhbXBs ZSBmcm9tIGhhcyBhbiBleHBlbnNpdmUgZnVuY3Rpb24uDQotLUl0IG1pZ2h0 IGJlIHdvcnRoIHRvIG5vdGUgdGhhdCB0aGlzIGZ1bmN0aW9uIGlzIChkZXNw aXRlIHRoZSByYW5kb20oKS1jYWxsKSBpbmRlZWQgZGV0ZXJtaW5pc3RpYyBh bmQgZnVydGhlcm1vcmUgaW5qZWN0aXZlLiBJbiB0aGUgb3JpZ2luYWwgZXhh bXBsZSBJIHN0cmlwZWQgZG93biB0aGUgZnVuY3Rpb24gd2Fzbid0IHN0cmlj dGx5IGluamVjdGl2ZS4NCmNyZWF0ZSBvciByZXBsYWNlIGZ1bmN0aW9uIGV4 cGVuc2l2ZV9mdW5jIChpZCBpbnQpIHJldHVybnMgaW50W10gDQphcw0KJ3Nl bGVjdCBhcnJheV9hZ2coZW50KSByIGZyb20gKHNlbGVjdCB1bm5lc3QoYXJy KSBlbnQgZnJvbSAoc2VsZWN0IGFycmF5KHNlbGVjdCBpIGZyb20gKHNlbGVj dCBnZW5lcmF0ZV9zZXJpZXMoaWQtNSxpZCkgaSkgZm9vIG9yZGVyIGJ5IHJh bmRvbSgpKSBhcnIpIGJhciBvcmRlciBieSBlbnQpIGZvbzsnDQpsYW5ndWFn ZSBzcWwgaW1tdXRhYmxlOyAtLUNvc3RzIG9mIHNldmVyYWwgaHVuZHJlZCB3 b3VsZCBwcm9iYWJseSBiZSBtb3JlIGFwcHJvcHJpYXRlLCBidXQgaXQgZG9l c24ndCBlZmZlY3QgdGhlIHBsYW5zLg0KDQoNCmRyb3AgdGFibGUgaWYgZXhp c3RzIHQ7DQpkcm9wIHRhYmxlIGlmIGV4aXN0cyB1Ow0KZHJvcCB0YWJsZSBp ZiBleGlzdHMgZm9vMTAwOw0KZHJvcCB0YWJsZSBpZiBleGlzdHMgZm9vNTAw MDA7DQoNCi0tVGhlc2UgY29sdW1ucyBhcmUgKGJlc2lkZXMgaWQgYW5kIGEp IG5lYXJseSBpbmRlcGVuZGVudC4NCmNyZWF0ZSB0YWJsZSB0IGFzIHNlbGVj dCBpZCwgY2FzZSB3aGVuIGlkJTExPjggdGhlbiAxMDAwMDAgZWxzZSBpZCBl bmQgYSwgaWQlMjM9MCBiLCBpZCUzPTAgYywgaWQlMTAwPTAgZCBmcm9tIChz ZWxlY3QgZ2VuZXJhdGVfc2VyaWVzKDEsMTAwMDAwMCkgaWQpIGZvbzsNCmNy ZWF0ZSB0YWJsZSB1IGFzIHNlbGVjdCBpZCwgYSwgYiwgYywgZCBmcm9tIHQg d2hlcmUgYzsNCg0KY3JlYXRlIHRhYmxlIGZvbzEwMCBhcyBzZWxlY3QgZ2Vu ZXJhdGVfc2VyaWVzKDEsMTAwKSBvOw0KY3JlYXRlIHRhYmxlIGZvbzUwMDAw IGFzIHNlbGVjdCBnZW5lcmF0ZV9zZXJpZXMoMSwxMDAwMCkgbzsNCi0tV2Ug ZG9uJ3QgbmVlZCB0aGVzZSB0YWJsZXMgbmVjZXNzYXJpbHkgLSBqdXN0IGlu bGluaW5nIHRoZXNlIGV4cHJlc3Npb25zIHdvdWxkIGRvIGZpbmUgKHNpbmNl IGJvdGggZGlmZmVyIG9ubHkgYnkgb25lIG9yZGVyIG9mIG1hZ25pdHVkZSBm cm9tIHRoZSBlc3RpbWF0ZSkuDQotLUJ1dCBpdCB3aWxsIG1ha2UgdGhlIHBs YW5zIHByb2R1Y2UgbXVjaCBtb3JlIHJlYXNvbmFibGUgZXN0aW1hdGVzLg0K DQpjcmVhdGUgdW5pcXVlIGluZGV4IG9uIHQgKGlkKTsNCmNyZWF0ZSB1bmlx dWUgaW5kZXggb24gdCAoZXhwZW5zaXZlX2Z1bmMoaWQpKTsNCmNyZWF0ZSBp bmRleCBvbiB0IChkKTsNCmNyZWF0ZSBpbmRleCBvbiB0IChjKSB3aGVyZSBi Ow0KY3JlYXRlIGluZGV4IG9uIHQgKGEpIHdoZXJlIG5vdCBkOw0KY3JlYXRl IHVuaXF1ZSBpbmRleCBvbiB1IChpZCk7DQpjcmVhdGUgaW5kZXggb24gdSAo YSkgd2hlcmUgYSA8IDEwMDAwMDsNCg0KdmFjdXVtIGFuYWx5emUgdDsNCnZh Y3V1bSBhbmFseXplIHU7DQp2YWN1dW0gYW5hbHl6ZSBmb28xMDA7DQp2YWN1 dW0gYW5hbHl6ZSBmb281MDAwMDsNCg0KDQoNCi0tZmlyc3QgY2FzZQ0KDQot LVBsYW5uaW5nIHRpbWU6IDAuMjI1IG1zDQotLUV4ZWN1dGlvbiB0aW1lOiA1 NC41MjkgbXMNCmV4cGxhaW4gKGFuYWx5c2UsIGJ1ZmZlcnMpDQpzZWxlY3Qg Y291bnQoKikgZnJvbSB0IHQwIHdoZXJlIGV4aXN0cyAoc2VsZWN0IG51bGwg ZnJvbSB0IHdoZXJlIHQuaWQ9MTAwMDAwIGFuZCB0MC5hPXQuYSkgYW5kIGIg YW5kIGMgYW5kIG5vdCBkOw0KDQotLVBsYW5uaW5nIHRpbWU6IDAuMDgxIG1z ICsgMC4xMzMgbXMgPSAwLjIxNCBtcw0KLS1FeGVjdXRpb24gdGltZTogMC4w NzcgbXMgKyAxNS4yNjQgbXMgPSAxNS4zNDEgbXMNCmV4cGxhaW4gKGFuYWx5 c2UsIGJ1ZmZlcnMpDQpzZWxlY3QgYSBmcm9tIHQgd2hlcmUgdC5pZD0xMDAw MDA7DQpleHBsYWluIChhbmFseXNlLCBidWZmZXJzKQ0Kc2VsZWN0IGNvdW50 KCopIGZyb20gdCB3aGVyZSBhPTEwMDAwMCBhbmQgYiBhbmQgYyBhbmQgbm90 IGQ7DQoNCg0KDQotLXNlY29uZCBjYXNlDQoNCi0tUGxhbm5pbmcgdGltZTog MC4xMzIgbXMNCi0tRXhlY3V0aW9uIHRpbWU6IDI5OC45NzMgbXMNCmV4cGxh aW4gKGFuYWx5c2UsIGJ1ZmZlcnMpDQpzZWxlY3QgaWQgZnJvbSB0IA0Kd2hl cmUgYSBpbiAoMSwyLDMsNCw1LDYsNyw4LDksMTAsMTEsMTIsMTMsMTQsMTUs MTYsMTcsMTgsMTksMjAsMjEsMjIsMjMsMjQsMjUsMjYsMjcsMjgsMjksMzAp Ow0KDQotLVBsYW5uaW5nIHRpbWU6IDAuMTc0IG1zDQotLUV4ZWN1dGlvbiB0 aW1lOiAxNTguNjY2IG1zDQpleHBsYWluIChhbmFseXNlLCBidWZmZXJzKQ0K c2VsZWN0IGlkIGZyb20gdA0Kd2hlcmUgZXhpc3RzIChzZWxlY3QgbnVsbCBm cm9tICh2YWx1ZXMgKDEpLCgyKSwoMyksKDQpLCg1KSwoNiksKDcpLCg4KSwo OSksKDEwKSwoMTEpLCgxMiksKDEzKSwoMTQpLCgxNSksKDE2KSwoMTcpLCgx OCksKDE5KSwoMjApLCgyMSksKDIyKSwoMjMpLCgyNCksKDI1KSwoMjYpLCgy NyksKDI4KSwoMjkpLCgzMCkpIGZvbyAoZm9vYSkgDQoJCXdoZXJlIGE9Zm9v YSk7DQoNCi0tSSBndWVzcyB0aGUgbGltaXRhdGlvbnMgb2YgY3JlYXRpbmcg YSBjb25zdGFudCB0YWJsZSBpcyBjbGVhciwganVzdCBpbiBjYXNlIGl0J3Mg bm90Og0KLS1QbGFubmluZyB0aW1lOiAwLjE0MiBtcw0KLS1FeGVjdXRpb24g dGltZTogNTAuNTUwIG1zDQpleHBsYWluIChhbmFseXNlLCBidWZmZXJzKQ0K c2VsZWN0IGlkIGZyb20gdQ0Kd2hlcmUgZXhpc3RzIChzZWxlY3QgbnVsbCBm cm9tICh2YWx1ZXMgKDEpLCgyKSwoMyksKDQpLCg1KSwoNiksKDcpLCg4KSwo OSksKDEwKSwoMTEpLCgxMiksKDEzKSwoMTQpLCgxNSksKDE2KSwoMTcpLCgx OCksKDE5KSwoMjApLCgyMSksKDIyKSwoMjMpLCgyNCksKDI1KSwoMjYpLCgy NyksKDI4KSwoMjkpLCgzMCkpIGZvbyAoZm9vYSkgDQoJCXdoZXJlIGE9Zm9v YSk7DQoNCi0tUGxhbm5pbmcgdGltZTogMC4xOTcgbXMNCi0tRXhlY3V0aW9u IHRpbWU6IDAuMDY2IG1zDQpleHBsYWluIChhbmFseXNlLCBidWZmZXJzKQ0K c2VsZWN0IGlkIGZyb20gdQ0Kd2hlcmUgYSBpbiAoMSwyLDMsNCw1LDYsNyw4 LDksMTAsMTEsMTIsMTMsMTQsMTUsMTYsMTcsMTgsMTksMjAsMjEsMjIsMjMs MjQsMjUsMjYsMjcsMjgsMjksMzApOw0KDQoNCg0KDQotLXRoaXJkIGNhc2UN Cg0KLS1QbGFubmluZyB0aW1lOiAwLjQ0OCBtcw0KLS1FeGVjdXRpb24gdGlt ZTogOTI5NS4xNTYgbXMNCmV4cGxhaW4gKGFuYWx5c2UsIGJ1ZmZlcnMpDQpz ZWxlY3QgaWQgZnJvbSB0IHdoZXJlIGV4aXN0cyAoc2VsZWN0IG51bGwgZnJv bSB1DQoJCXdoZXJlIHQuaWQ9dS5pZA0KCQkJYW5kIGV4aXN0cyAoc2VsZWN0 IG51bGwgZnJvbSBmb28xMDAgd2hlcmUgZXhwZW5zaXZlX2Z1bmMobyk9ZXhw ZW5zaXZlX2Z1bmModS5pZCkpKQ0KCWFuZCBub3QgZDsNCg0KLS1QbGFubmlu ZyB0aW1lOiAwLjU1NiBtcw0KLS1FeGVjdXRpb24gdGltZTogOC43NjcgbXMN CmV4cGxhaW4gKGFuYWx5c2UsIGJ1ZmZlcnMpDQpzZWxlY3QgaWQgZnJvbSB0 IHdoZXJlIGV4aXN0cyAoc2VsZWN0IG51bGwgZnJvbSB1DQoJCXdoZXJlIHQu aWQ9dS5pZA0KCQkJYW5kIGV4aXN0cyAoc2VsZWN0IG51bGwgZnJvbSBmb28x MDAgd2hlcmUgZXhwZW5zaXZlX2Z1bmMobyk9ZXhwZW5zaXZlX2Z1bmModC5p ZCkpKQ0KCWFuZCBub3QgZDsNCg0KLS1QbGFubmluZyB0aW1lOiAwLjQ0MyBt cw0KLS1FeGVjdXRpb24gdGltZTogMzEzLjk5NyBtcw0KZXhwbGFpbiAoYW5h bHlzZSwgYnVmZmVycykNCnNlbGVjdCBpZCBmcm9tIHQNCndoZXJlIGV4aXN0 cyAoc2VsZWN0IG51bGwgZnJvbSB1DQoJCXdoZXJlIHQuaWQ9dS5pZA0KCQkJ YW5kIGV4aXN0cyAoc2VsZWN0IG51bGwgZnJvbSBmb281MDAwMCB3aGVyZSBl eHBlbnNpdmVfZnVuYyhvKT1leHBlbnNpdmVfZnVuYyh1LmlkKSkpDQoJYW5k IGQ7DQoNCi0tUGxhbm5pbmcgdGltZTogMC42NzggbXMNCi0tRXhlY3V0aW9u IHRpbWU6IDYwMi4wNTIgbXMNCmV4cGxhaW4gKGFuYWx5c2UsIGJ1ZmZlcnMp DQpzZWxlY3QgaWQgZnJvbSB0DQp3aGVyZSBleGlzdHMgKHNlbGVjdCBudWxs IGZyb20gdQ0KCQl3aGVyZSB0LmlkPXUuaWQNCgkJCWFuZCBleGlzdHMgKHNl bGVjdCBudWxsIGZyb20gZm9vNTAwMDAgd2hlcmUgZXhwZW5zaXZlX2Z1bmMo byk9ZXhwZW5zaXZlX2Z1bmModC5pZCkpKQ0KCWFuZCBkOw0KLS1JIGRvbid0 IHRoaW5rIHRoaXMgcGxhbiBpcyBvcHRpbWFsLCBidXQgdGhpcyB0YXNrIGlz IG5vbiB0aGUgbGVzcyBtdWNoIGhhcmRlciB0aGFuIHRoZSBvbmUgYWJvdmUu --_004_d93e3d0527514efc94975dceaf71442eindexde_ Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance --_004_d93e3d0527514efc94975dceaf71442eindexde_--