Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1alywy-0000Ko-Rh for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2016 13:17:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1alywy-0003mz-Ee for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2016 13:17:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1alywx-0003mg-Mr for pgsql-performance@postgresql.org; Fri, 01 Apr 2016 13:17:19 +0000 Received: from mail-yw0-x232.google.com ([2607:f8b0:4002:c05::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1alywt-0002yk-62 for pgsql-performance@postgresql.org; Fri, 01 Apr 2016 13:17:19 +0000 Received: by mail-yw0-x232.google.com with SMTP id h65so158720661ywe.0 for ; Fri, 01 Apr 2016 06:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=P+EVnJAksqT1CbqFX2EdZqX4rEzsmf8gqYYhGj5n3Zw=; b=UuOjqvFlivQUVHQMw9sdPon7/UnwkQo29mM2jG4R9MXj7H4pcFz+CrPlnjkAo4YWVX kL3CMG1zfUtEaWkdAc3367HIgOxp6+KjbtTUyDsMl6BMi6bwfplkfdu9kX++cS/J0qw+ 995s4ThbzZFGkaB/KxOfgeXguz6HlQ84KtFOqggetThIwyrzjs3Cg2KXCgeGU3Mt7ILv KvOfNwCskpC5TtkLX/zUACTkDW1Fltrtobu8gSQkldsMfi8R3yy+jpAd2RiYI75epMN0 CZlttivHtgxtBgAf5yKZEIRPwSnrnWMuDiBal/zQnNjT5g6IpCibmQOk04twbrqFv6dK dF6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=P+EVnJAksqT1CbqFX2EdZqX4rEzsmf8gqYYhGj5n3Zw=; b=bC3gcqrmtxI0B/k2W007LuHU9ESu24XKhDsWMs0uf4h56cNpR32RreTSLTFGJyQ6/K uI/HyfcdcuTKL6ETZkNe7Vmmxya87cTAYt7GRnyYinqubV+T24I4U+firEBzNZniGCGM lwK3AcS8lzedvLa1FTPUyxKgAjIG4zulUMjTf6KwW7SOZ5CjXGatqxEzNxtdLYRSPmRx U+JmQqtqS261+RHPxaife2CJmFHFeYINjoYIqjpCABgRJnITqU/RsfacnsK+6XSpAh1k UaZNUXasHtKs+4bQtJBlD8dhU50emMVHloQxGP1b7DQh3YaMwYFM2WzIKB7dvFyGaUB8 020g== X-Gm-Message-State: AD7BkJLvR+a8ZjWaUUfyDEJG33MAYyrJrsi9Yl9Ux2r6TyIUWb3MIuzxKek1/6FrgSLSZpEYlSPKIfQQ+9vxLbc0 MIME-Version: 1.0 X-Received: by 10.37.80.141 with SMTP id e135mr11520303ybb.49.1459516633016; Fri, 01 Apr 2016 06:17:13 -0700 (PDT) Received: by 10.129.85.17 with HTTP; Fri, 1 Apr 2016 06:17:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2016 02:17:12 +1300 Message-ID: Subject: Re: Fast HashJoin only after a cluster/recreate table From: David Rowley To: Alexandre de Arruda Paes Cc: postgres performance list Content-Type: multipart/alternative; boundary=001a113e54ee74c4b5052f6c3223 X-Pg-Spam-Score: -2.6 (--) 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 --001a113e54ee74c4b5052f6c3223 Content-Type: text/plain; charset=UTF-8 On 1 April 2016 at 15:44, Alexandre de Arruda Paes wrote: > In the query below, the planner choose an extreme slow mergejoin(380 > seconds). 'Vacuum analyze' can't help. > Yeah, it appears that planner is estimating the WHERE clause on es09t quite badly, expecting just 1 row, but there's actually 1212 rows. This seems to throw the whole plan decision out quite a bit, as, if you notice in the merge left join for t1.es09tipdoc = t2.es08tipdoc, it expect just 2 rows to be present, therefore most likely thinks that it's not worth sorting those results on t1.es09tipdoc, t1.es09numdoc in order for it to match the known output order of Materialize node on the inner side of that join. Instead it assumes the Merge join will be good enough on just the es09tipdoc order, and just adds the other two columns as join filters.... ... and this seems to be what's killing the performance. This Merge Join constantly has to perform a mark/restore on the Materialize node. This why you're getting the insanely high "Rows Removed by Join Filter: 992875295", in other words the join filter throw away that many row combinations because they didn't match. This mark/restore is basically the rewind process that the merge join algorithm needs to do to match many to many rows. In actual fact, this rewind is pretty useless in this case as the GROUP BY subquery ensures that no duplicate values will make it into the inner side of that merge join. The planner is not currently smart enough to detect this. There are some patches currently pending for 9.6 which might help fix this problem in the future; 1. multivariate statistics; this might help the poor estimates on es09t. If this was available you could add statistics on es09codemp, es09datreq, which may well improve the estimate and cause the plan to change. https://commitfest.postgresql.org/9/450/ 2. Unique joins. This tackles the problem a different way and allows the Merge Join algorithm to skip the restore with some new smarts that are added to the planner to detect when the inner side of the join can only produce, at most, a single row for each outer row. https://commitfest.postgresql.org/9/129/ If you feel like compiling 9.6 devel from source and applying each of these patches independently and seeing if it helps... Of course that does not solve your 9.4 production dilemma, but it may help evaluation of each of these two patches for 9.6 or beyond. I wonder what the planner would do if you pulled out the join to ES08T. If that generates a better plan, then providing that es08tipdoc is the primary key of that table, then you could just put a subquery in the SELECT clause to lookup the es08desdoc. > > QUERY PLAN > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Sort (cost=289546.93..289546.94 rows=2 width=78) (actual > time=380405.796..380405.929 rows=2408 loops=1) > Sort Key: t1.es09numdoc, t1.es09tipdoc > Sort Method: quicksort Memory: 435kB > Buffers: shared hit=82163 > -> Merge Left Join (cost=47.09..289546.92 rows=2 width=78) (actual > time=1133.077..380398.160 rows=2408 loops=1) > Merge Cond: (t1.es09tipdoc = es09t1.es09tipdoc) > Join Filter: ((es09t1.es09codemp = t1.es09codemp) AND > (es09t1.es09numdoc = t1.es09numdoc)) > Rows Removed by Join Filter: 992875295 > Buffers: shared hit=82163 > -> Merge Left Join (cost=46.53..49.29 rows=2 width=70) (actual > time=12.206..18.155 rows=2408 loops=1) > Merge Cond: (t1.es09tipdoc = t2.es08tipdoc) > Buffers: shared hit=6821 > -> Sort (cost=9.19..9.19 rows=2 width=44) (actual > time=11.611..12.248 rows=2408 loops=1) > Sort Key: t1.es09tipdoc > Sort Method: quicksort Memory: 285kB > Buffers: shared hit=6814 > -> Nested Loop (cost=1.11..9.18 rows=2 width=44) > (actual time=0.040..10.398 rows=2408 loops=1) > Buffers: shared hit=6814 > -> Index Scan using ad_es09t_1 on es09t t3 > (cost=0.56..4.58 rows=1 width=42) (actual time=0.020..0.687 rows=1212 > loops=1) > Index Cond: ((es09codemp = 1) AND > (es09datreq >= '2016-02-02'::date) AND (es09datreq <= '2016-02-02'::date)) > Filter: (es09usuari ~~ > '%%%%%%%%%%%%%%%%%%%%'::text) > Buffers: shared hit=108 > -> Index Scan using es09t1_pkey on es09t1 t1 > (cost=0.56..4.59 rows=1 width=19) (actual time=0.006..0.007 rows=2 > loops=1212) > Index Cond: ((es09codemp = 1) AND > (es09tipdoc = t3.es09tipdoc) AND (es09numdoc = t3.es09numdoc)) > Filter: (es09tipdoc ~~ '%%%%%'::text) > Buffers: shared hit=6706 > -> Sort (cost=37.35..38.71 rows=547 width=32) (actual > time=0.592..2.206 rows=2919 loops=1) > Sort Key: t2.es08tipdoc > Sort Method: quicksort Memory: 67kB > Buffers: shared hit=7 > -> Seq Scan on es08t t2 (cost=0.00..12.47 rows=547 > width=32) (actual time=0.003..0.126 rows=547 loops=1) > Buffers: shared hit=7 > -> Materialize (cost=0.56..287644.85 rows=716126 width=23) > (actual time=0.027..68577.800 rows=993087854 loops=1) > Buffers: shared hit=75342 > -> GroupAggregate (cost=0.56..278693.28 rows=716126 > width=15) (actual time=0.025..4242.453 rows=3607573 loops=1) > Group Key: es09t1.es09codemp, es09t1.es09tipdoc, > es09t1.es09numdoc > Buffers: shared hit=75342 > -> Index Only Scan using es09t1_pkey on es09t1 > (cost=0.56..199919.49 rows=7161253 width=15) (actual time=0.016..1625.031 > rows=7160921 loops=1) > Index Cond: (es09codemp = 1) > Heap Fetches: 51499 > Buffers: shared hit=75342 > Planning time: 50.129 ms > Execution time: 380419.435 ms > -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services --001a113e54ee74c4b5052f6c3223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= April 2016 at 15:44, Alexandre de Arruda Paes <adaldeia@gmail.com>= ; wrote:
In the query belo= w, the planner choose an extreme slow mergejoin(380 seconds). 'Vacuum a= nalyze' can't help.

Yeah, it appears that planner is estimating the WHERE clause on es09t quit= e badly, expecting just 1 row, but there's actually=C2=A01212 rows.=C2= =A0 This seems to throw the whole plan decision out quite a bit, as, if you= notice in the merge left join for t1.es09tipdoc =3D t2.es08tipdoc, it expe= ct just 2 rows to be present, therefore most likely thinks that it's no= t worth sorting those results on t1.es09tipdoc,=C2=A0t1.es09numdoc in order= for it to match the known output order of Materialize node on the inner si= de of that join. Instead it assumes the Merge join will be good enough on j= ust the es09tipdoc order, and just adds the other two columns as join filte= rs....

... and this seems to be what's killing= the performance. This Merge Join constantly has to perform a mark/restore = on the Materialize node. This why you're getting the insanely high &quo= t;Rows Removed by Join Filter: 992875295", in other words the join fil= ter throw away that many row combinations because they didn't match.

This mark/restore is basically the rewind process th= at the merge join algorithm needs to do to match many to many rows. In actu= al fact, this rewind is pretty useless in this case as the GROUP BY subquer= y ensures that no duplicate values will make it into the inner side of that= merge join. The planner is not currently smart enough to detect this.

There are some patches currently pending for 9.6 which= might help fix this problem in the future;

1. mul= tivariate statistics; this might help the poor estimates on es09t. If this = was available you could add statistics on es09codemp, es09datreq, which may= well improve the estimate and cause the plan to change. https://commitfest.postgresql.org/9/450/=
2. Unique joins. This tackles the problem a different way an= d allows the Merge Join algorithm to skip the restore with some new smarts = that are added to the planner to detect when the inner side of the join can= only produce, at most, a single row for each outer row.=C2=A0https://commitfest.postgresql.org/9= /129/

If you feel like compiling 9.6 devel fro= m source and applying each of these patches independently and seeing if it = helps...=C2=A0 Of course that does not solve your 9.4 production dilemma, b= ut it may help evaluation of each of these two patches for 9.6 or beyond.

I wonder what the planner would do if you pulled ou= t the join to=C2=A0ES08T. If that generates a better plan, then providing t= hat=C2=A0es08tipdoc is the primary key of that table, then you could just p= ut a subquery in the SELECT clause to lookup the=C2=A0es08desdoc.
=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QUERY PLAN =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
------------------------= ---------------------------------------------------------------------------= -------------------------------------------------------------------
=C2=A0Sort =C2=A0(cost=3D289546.93..289546.94 rows=3D2 width=3D78) (actu= al time=3D380405.796..380405.929 rows=3D2408 loops=3D1)
=C2=A0 = =C2=A0Sort Key: t1.es09numdoc, t1.es09tipdoc
=C2=A0 =C2=A0Sort Me= thod: quicksort =C2=A0Memory: 435kB
=C2=A0 =C2=A0Buffers: shared = hit=3D82163
=C2=A0 =C2=A0-> =C2=A0Merge Left Join =C2=A0(cost= =3D47.09..289546.92 rows=3D2 width=3D78) (actual time=3D1133.077..380398.16= 0 rows=3D2408 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Merge = Cond: (t1.es09tipdoc =3D es09t1.es09tipdoc)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Join Filter: ((es09t1.es09codemp =3D t1.es09codemp) AND (es09t= 1.es09numdoc =3D t1.es09numdoc))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Rows Removed by Join Filter: 992875295
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Buffers: shared hit=3D82163
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-> =C2=A0Merge Left Join =C2=A0(cost=3D46.53..49.29 rows=3D2 w= idth=3D70) (actual time=3D12.206..18.155 rows=3D2408 loops=3D1)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Merge Cond: (t1.es09= tipdoc =3D t2.es08tipdoc)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Buffers: shared hit=3D6821
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0Sort =C2=A0(cost=3D9.19..9.19= rows=3D2 width=3D44) (actual time=3D11.611..12.248 rows=3D2408 loops=3D1)<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Sort Key: t1.es09tipdoc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sort Method: quicksort =C2= =A0Memory: 285kB
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit=3D6814
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2= =A0Nested Loop =C2=A0(cost=3D1.11..9.18 rows=3D2 width=3D44) (actual time= =3D0.040..10.398 rows=3D2408 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bu= ffers: shared hit=3D6814
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0Inde= x Scan using ad_es09t_1 on es09t t3 =C2=A0(cost=3D0.56..4.58 rows=3D1 width= =3D42) (actual time=3D0.020..0.687 rows=3D1212 loops=3D1)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Index Cond: ((es09codemp =3D 1) AND (= es09datreq >=3D '2016-02-02'::date) AND (es09datreq <=3D '= ;2016-02-02'::date))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Filter: (es09usuari ~~ '%%%%%%%%%%%%%%%%%%%%'::text)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit=3D108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0Index Scan using es09t1_pkey on es0= 9t1 t1 =C2=A0(cost=3D0.56..4.59 rows=3D1 width=3D19) (actual time=3D0.006..= 0.007 rows=3D2 loops=3D1212)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Index Cond: ((es09codemp =3D 1) AND (es09tipdoc =3D t3.es09tipdoc= ) AND (es09numdoc =3D t3.es09numdoc))
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Filter: (es09tipdoc ~~ '%%%%%'::text)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit=3D6706
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0S= ort =C2=A0(cost=3D37.35..38.71 rows=3D547 width=3D32) (actual time=3D0.592.= .2.206 rows=3D2919 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sort Key: t2.es08tipdoc
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Sort Method: quicksort =C2=A0Memory: 67kB
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit= =3D7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-> =C2=A0Seq Scan on es08t t2 =C2=A0(cost=3D0.00..12.47= rows=3D547 width=3D32) (actual time=3D0.003..0.126 rows=3D547 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit=3D7
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0Materialize =C2=A0(cost=3D0.56..287644.= 85 rows=3D716126 width=3D23) (actual time=3D0.027..68577.800 rows=3D9930878= 54 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Buffers: shared hit=3D75342
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0GroupAggregate =C2=A0(cost=3D0.56..2786= 93.28 rows=3D716126 width=3D15) (actual time=3D0.025..4242.453 rows=3D36075= 73 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Group Key: es09t1.es09codemp, es09t1.es09tipdoc,= es09t1.es09numdoc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Buffers: shared hit=3D75342
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0->= =C2=A0Index Only Scan using es09t1_pkey on es09t1 =C2=A0(cost=3D0.56..1999= 19.49 rows=3D7161253 width=3D15) (actual time=3D0.016..1625.031 rows=3D7160= 921 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Index Cond: (es09codemp =3D= 1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Heap Fetches: 51499
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Buffers: shared hit=3D75342
=C2=A0Planning time:= 50.129 ms
=C2=A0Execution time: 380419.435 ms
<= /blockquote>


--
=
=C2=A0David Rowley =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0http://www.2ndQuadrant.com/
=C2=A0PostgreSQL Development, = 24x7 Support, Training & Services
<= /div>
--001a113e54ee74c4b5052f6c3223--