Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am2y4-0002JX-E3 for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2016 17:34:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1am2y3-0001xj-Ld for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2016 17:34:43 +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 1am2y2-0001xH-Mb for pgsql-performance@postgresql.org; Fri, 01 Apr 2016 17:34:43 +0000 Received: from mail-oi0-x22c.google.com ([2607:f8b0:4003:c06::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1am2xz-0006GW-Be for pgsql-performance@postgresql.org; Fri, 01 Apr 2016 17:34:41 +0000 Received: by mail-oi0-x22c.google.com with SMTP id o62so114908075oig.1 for ; Fri, 01 Apr 2016 10:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tG6IfZpQTsW+AP5wO0D8K955LBykb7pEzM4WqWrxWUo=; b=NzCV6NN0D83ImOowK7oD8IYo9tupBxC6MJzGAY0q97QEXYWgbXuN6gmPSWT6tOa6cx bBixaanzNvzY47nLWDIQ0j/OQ5W6PK7/Dk3pp8iftyWJxgaEt4Zth+HlXOedixLUBt/D mtMnINXUvSmh8WtNHlmd4qpNhhrg3mNAcNPnLRQPzdo8Ak6VKxYMoSOya92MMlYqmkTo xH+vkDX7eR1E7T++aYBEZxoq1+KHbkI5h5rBBHVBei3xWfaCTO8x57dBRW8mi+1BRU8T rF6dFQU5gZ5dkvbNlGM0z9Ns4nMdIYTUOd2BK9FF3J9Xo8Yx5Meqs+nl3YM86TtzJAks j+qw== 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=tG6IfZpQTsW+AP5wO0D8K955LBykb7pEzM4WqWrxWUo=; b=lq2YqRFbAPEVqKUqLh1CY5bATJOB64h94CezQuVhU8ee63adtbijyrkHSX4DasSVCC CSxTqUa/GtrSDPjkGtyrZCnLA3Z2YTDfwpT2759cH0he9v7YFUEKzbroIkIsa0kdRg1j RGO7wCTkpJhIaCA7jVLVSg8XzLz7KufGe/nAc564VK9iGpK8uwGdwHi2YrIQHKiohcIv 5KzuauDkcmppcT10Y6t2ewYnLbt5bAb4L/lRbETV815ap+EvvJwiWAJAEoJRXXtl0Va8 KrQJcoX99s+JEEdI5KBOzGwN9Y+16wpUSZeTYW01fxJnrencd2raHBPeAHS6/8b8usMr x6aw== X-Gm-Message-State: AD7BkJJUY7GbmevJsJtg12EWYWRy0ECGmmHJBC0PSt1MEeH71D0x2YJUaUkcs1H+08AKOHEHCgBGaHkUe9AZPQ== MIME-Version: 1.0 X-Received: by 10.157.24.107 with SMTP id t40mr1773728ott.142.1459532077398; Fri, 01 Apr 2016 10:34:37 -0700 (PDT) Received: by 10.157.33.201 with HTTP; Fri, 1 Apr 2016 10:34:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2016 14:34:37 -0300 Message-ID: Subject: Re: Fast HashJoin only after a cluster/recreate table From: Alexandre de Arruda Paes To: David Rowley Cc: postgres performance list Content-Type: multipart/alternative; boundary=001a1142de900300da052f6fcb62 X-Pg-Spam-Score: -2.7 (--) 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 --001a1142de900300da052f6fcb62 Content-Type: text/plain; charset=UTF-8 Hi David, Thanks for the explanations. But I don't undestand why when I recreate the table, the planner choose a best mode for sometime... >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. We have a problem with this approach. Actually, this querys are generated by a framework and can't be 'rewrite'. Can you think in another solution directly in DB (perhaps a partial index, table partitioning, etc) ??? Best regards, Alexandre 2016-04-01 10:17 GMT-03:00 David Rowley : > 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 > --001a1142de900300da052f6fcb62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

Thanks for the explanations. = But I don't undestand why when I recreate the table, the planner choose= a best mode for sometime...

>I wonder wha= t the planner would do if you pulled out the join to=C2=A0ES08T. If that ge= nerates a better plan, then providing that=C2=A0es08tipdoc is the primary k= ey of that table, then you could just put a=C2=A0
> subquery i= n the SELECT clause to lookup the=C2=A0es08desdoc.

We have a problem with this approach. Actually= , this querys are generated by a framework and can't be 'rewrite= 9;.=C2=A0
Can you think in another solution directly in DB (perha= ps a partial index, table partitioning, etc) ???

B= est regards,

Alexandre


2016-04-01 10:1= 7 GMT-03:00 David Rowley <david.rowley@2ndquadrant.com><= /span>:
On 1 April 2016 at 15:44, Alexandre de Arruda= Paes <adaldeia@gmail.com> wrote:
In the query below, the planner choose an extreme slow mer= gejoin(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=C2=A01212 rows.=C2=A0 This seems to throw the whole p= lan decision out quite a bit, as, if you notice in the merge left join for = t1.es09tipdoc =3D t2.es08tipdoc, it expect just 2 rows to be present, there= fore most likely thinks that it's not worth sorting those results on t1= .es09tipdoc,=C2=A0t1.es09numdoc in order for it to match the known output o= rder 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 c= onstantly has to perform a mark/restore on the Materialize node. This why y= ou're getting the insanely high "Rows Removed by Join Filter: 9928= 75295", in other words the join filter throw away that many row combin= ations because they didn't match.

This mark/re= store is basically the rewind process that the merge join algorithm needs t= o do to match many to many rows. In actual fact, this rewind is pretty usel= ess 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 cur= rently 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 he= lp the poor estimates on es09t. If this was available you could add statist= ics on es09codemp, es09datreq, which may well improve the estimate and caus= e the plan to change. https://commitfest.postgresql.org/9/450/
2.= Unique joins. This tackles the problem a different way and allows the Merg= e 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 fr= om 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, = but it may help evaluation of each of these two patches for 9.6 or beyond.<= /div>

I wonder what the planner would do if you pulled o= ut the join to=C2=A0ES08T. If that generates a better plan, then providing = that=C2=A0es08tipdoc is the primary key of that table, then you could just = put 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) (actual time=3D380405.796..380405.929 rows=3D2408 loops=3D1)
=C2=A0 =C2=A0Sort Key: t1.es09numdoc, t1.es09tipdoc
=C2=A0 =C2= =A0Sort Method: quicksort =C2=A0Memory: 435kB
=C2=A0 =C2=A0Buffer= s: 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.160 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.es09code= mp) AND (es09t1.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 width=3D70) (actual time=3D12.206..18.155 rows=3D2408 loops=3D= 1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Merge C= ond: (t1.es09tipdoc =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(cos= t=3D9.19..9.19 rows=3D2 width=3D44) (actual time=3D11.611..12.248 rows=3D24= 08 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: 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=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=A0 =C2=A0 =C2=A0-&= gt; =C2=A0Index 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: ((es09codem= p =3D 1) AND (es09datreq >=3D '2016-02-02'::date) AND (es09datre= q <=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 es09= t1_pkey on es09t1 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-&= gt; =C2=A0Sort =C2=A0(cost=3D37.35..38.71 rows=3D547 width=3D32) (actual ti= me=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 lo= ops=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.5= 6..287644.85 rows=3D716126 width=3D23) (actual time=3D0.027..68577.800 rows= =3D993087854 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=3D= 0.56..278693.28 rows=3D716126 width=3D15) (actual time=3D0.025..4242.453 ro= ws=3D3607573 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.es0= 9tipdoc, 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..199919.49 rows=3D7161253 width=3D15) (actual time=3D0.016..1625.031 row= s=3D7160921 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: (es09cod= emp =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=A0Plannin= g time: 50.129 ms
=C2=A0Execution time: 380419.435 ms
=


--
=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=A0= PostgreSQL Development, 24x7 Support, Training & Services
<= /div>

--001a1142de900300da052f6fcb62--