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.89) (envelope-from ) id 1ifAMJ-0002GS-Ej for pgsql-performance@arkaria.postgresql.org; Wed, 11 Dec 2019 22:21:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ifAMH-0003jH-EB for pgsql-performance@arkaria.postgresql.org; Wed, 11 Dec 2019 22:21:25 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1if83r-000668-JV for pgsql-performance@lists.postgresql.org; Wed, 11 Dec 2019 19:54:15 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1if83i-0005mc-Te for pgsql-performance@lists.postgresql.org; Wed, 11 Dec 2019 19:54:15 +0000 Received: by mail-wr1-x442.google.com with SMTP id c9so25453577wrw.8 for ; Wed, 11 Dec 2019 11:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netwidz-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=TP5NoxBFvzHp+aq0ZWzMfBDpoHiNMED9TUc7zE4dCnQ=; b=gNmR8RO4ePaz72HFT19/eHbyZVQoGdIFyuBlc60TXNgHQ2G1hZzNUzhXRzD67Heq2c ulhXM501XIch0JKlbadA7LuZeIjyj9kgHOPEfap+okz9d73TKJdRs4El784XPblnc5yz 09RsyKi5MBDFYNkjlhGPEFGsOoYt4w9grDTtYuceeZMYpi3Fur8JGkKSKBw6MgrWVp/t 9r6PQhmIBTZ5RvqRMzU1sVrJlfo8PPNdFtLb5hW9wUjbZfif2TbjwFYg4c0pJwn0RbS2 GOw/kDsn/JLgATZfnCtIyboeVcjI+fNdKmg6/+JYhEKhHLM+NxhPOUKSGGfoLV3xNsW7 Iacg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=TP5NoxBFvzHp+aq0ZWzMfBDpoHiNMED9TUc7zE4dCnQ=; b=cg7UpqzlAQshG9O4b8oHxRBoqaKS5Z987r9iQAYUL1E1oYy0tDsQvv07F0UnPgZp0e mx6uLJdF4SPSriha7I7TophdRnESdilyz0zQWmvaWG6oK2Vsx+bHBoMt03PdRtaTv/Bg +/f967nvAbACcI8IS2Fq1AZ4vzKXaM+twuiOQv+vwbWueaeNypvpui/b0/UVknhVvx8g O9kokMJTwYhrE4QLucc9tzM6XQru02ddpNzgjuTtUAC/h5/siBn6mpXODruIrlLAOusj x0lqlxpYNUAJEW39qSat4BUCiujPJF08qrHUwZTq78l0goz8bHOomizNFl73MI9j73++ yKvA== X-Gm-Message-State: APjAAAVFdpxdWP5kAqknU/gSZsQpDGs99XkvqCNJagB+3FqLMNr/syk2 BZvxwh2Ft1nmhSjMmIPEzHbpGw== X-Google-Smtp-Source: APXvYqyU8iVEh8Nrf53xyP8lht9qMyzsLp4P5yt/VF8V9UsMjW2Z0WYEPOhnpkLsk+llUMUOF1m28Q== X-Received: by 2002:adf:fd07:: with SMTP id e7mr1626975wrr.21.1576094045000; Wed, 11 Dec 2019 11:54:05 -0800 (PST) Received: from [192.168.1.6] ([90.240.4.171]) by smtp.gmail.com with ESMTPSA id w13sm3628955wru.38.2019.12.11.11.54.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 11:54:04 -0800 (PST) Date: Wed, 11 Dec 2019 19:53:57 +0000 From: Fahiz Mohamed To: Michael Lewis Cc: Pgsql Performance Message-ID: <7cb455c5-dd6a-4f33-bdbe-92033f7986e2@Spark> In-Reply-To: References: <6bd9b9b7-f127-4e48-a456-b3bbcfb741ab@Spark> <10b65cf1-a079-4aa3-92f0-ca21375da683@Spark> Subject: Re: Specific query taking time to process X-Readdle-Message-ID: 7cb455c5-dd6a-4f33-bdbe-92033f7986e2@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5df1495a_a0382c5_142" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --5df1495a_a0382c5_142 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There is a slight different in both instance=E2=80=99s data. Inastanbce 1= contains latest data and instance 2 consists of data which is 3 weeks ol= der than instance 1. =46ollowing are the number of rows in each table in both instances Instance 1 alf=5Fnode : 96493129 rows alf=5Fnode=5Fproperties : 455599288 rows alf=5Fnode=5Faspects : 150153006 rowsInstance 2 alf=5Fnode : 90831396 rows alf=5Fnode=5Fproperties : 440792247 rows alf=5Fnode=5Faspects : 146648241 rows I hope the above data difference can make a drastic difference. Please co= rrect me if I am wrong. I checked =22pg=5Fstat=5Fuser=5Ftables=22 and autovacuum never run agains= t those tables. I did execute vacuum manually and I noticed the below in the output =22IN=46O: vacuuming =22public.alf=5Fnode=5Faspects=22 IN=46O: =22alf=5Fnode=5Faspects=22: found 0 removable, 150264654 nonremov= able row versions in 812242 pages DETAIL: 0 dead row versions cannot be removed yet. CPU 13.53s/33.35u sec elapsed 77.88 sec. IN=46O: analyzing =22public.alf=5Fnode=5Faspects=22 IN=46O: =22alf=5Fnode=5Faspects=22: scanned 30000 of 812242 pages, contai= ning 5550000 live rows and 0 dead rows; 30000 rows in sample, 150264770 e= stimated total rows=22 Did the vacuum worked fine=3F I did =22explain( analyze, buffers )=22 below are the results: Instance 1: =C2=A0Nested Loop Semi Join (cost=3D441133.07..1352496.76 rows=3D1 width=3D= 8) (actual time=3D9054.324..10029.748 rows=3D22 loops=3D1) Buffers: shared hit=3D1617812 -> Merge Semi Join (cost=3D441132.50..1352359.19 rows=3D41 width=3D16) (a= ctual time=3D9054.296..10029.547 rows=3D22 loops=3D1) Merge Cond: (node.id =3D prop.node=5Fid) Buffers: shared hit=3D1617701 -> Index Only Scan using idx=5Falf=5Fnode=5Ftqn on alf=5Fnode node (cost=3D= 441041.93..1340831.48 rows=3D4593371 width=3D8) (actual t ime=3D4.418..7594.637 rows=3D40998148 loops=3D1) Index Cond: ((type=5Fqname=5Fid =3D 240) AND (store=5Fid =3D 6)) =46ilter: (NOT (hashed SubPlan 1)) Rows Removed by =46ilter: 130 Heap =46etches: 0 Buffers: shared hit=3D1617681 SubPlan 1 -> Bitmap Heap Scan on alf=5Fnode=5Faspects aspect=5F1 (cost=3D3418.63..4= 40585.22 rows=3D182459 width=3D8) (actual time=3D0. 583..2.992 rows=3D4697 loops=3D1) Recheck Cond: (qname=5Fid =3D 251) Heap Blocks: exact=3D1774 Buffers: shared hit=3D1791 -> Bitmap Index Scan on fk=5Falf=5Fnasp=5Fqn (cost=3D0.00..3373.01 rows=3D= 182459 width=3D0) (actual time=3D0.384..0.38 4 rows=3D4697 loops=3D1) Index Cond: (qname=5Fid =3D 251) Buffers: shared hit=3D17 -> Index Only Scan using idx=5Falf=5Fnprop=5Fs on alf=5Fnode=5Fproperties= prop (cost=3D0.70..41.74 rows=3D852 width=3D8) (actual time=3D 0.022..0.037 rows=3D23 loops=3D1) Index Cond: ((qname=5Fid =3D '242'::bigint) AND (string=5Fvalue =3D 'E292= 432'::text)) Heap =46etches: 0 Buffers: shared hit=3D20 -> Index Only Scan using alf=5Fnode=5Faspects=5Fpkey on alf=5Fnode=5Faspe= cts aspect (cost=3D0.57..38.80 rows=3D14 width=3D8) (actual time=3D0. 007..0.007 rows=3D1 loops=3D22) Index Cond: ((node=5Fid =3D node.id) AND (qname=5Fid =3D 245)) Heap =46etches: 22 Buffers: shared hit=3D111 Planning time: 0.621 ms Execution time: 10029.799 ms (29 rows) Instance 2: Nested Loop Semi Join (cost=3D6471.94..173560891.23 rows=3D2 width=3D8) (= actual time=3D0.162..0.470 rows=3D17 loops=3D1) Buffers: shared hit=3D257 -> Nested Loop (cost=3D6471.37..173560734.51 rows=3D45 width=3D16) (actua= l time=3D0.154..0.392 rows=3D17 loops=3D1) Buffers: shared hit=3D172 -> HashAggregate (cost=3D3508.15..3516.80 rows=3D865 width=3D8) (actual t= ime=3D0.039..0.043 rows=3D18 loops=3D1) Group Key: prop.node=5Fid Buffers: shared hit=3D23 -> Index Only Scan using idx=5Falf=5Fnprop=5Fs on alf=5Fnode=5Fproperties= prop (cost=3D0.70..3505.99 rows=3D866 width=3D8) (actual time=3D0.019..0.033 rows=3D18 loops=3D1) Index Cond: ((qname=5Fid =3D '242'::bigint) AND (string=5Fvalue =3D 'E292= 432'::text)) Heap =46etches: 18 Buffers: shared hit=3D23 -> Index Scan using alf=5Fnode=5Fpkey on alf=5Fnode node (cost=3D2963.22.= .200644.17 rows=3D1 width=3D8) (actual time=3D0.019.. 0.019 rows=3D1 loops=3D18) Index Cond: (id =3D prop.node=5Fid) =46ilter: ((type=5Fqname=5Fid <> 145) AND (store=5Fid =3D 6) AND (type=5F= qname=5Fid =3D 240) AND (NOT (SubPlan 1))) Rows Removed by =46ilter: 0 Buffers: shared hit=3D149 SubPlan 1 -> Materialize (cost=3D2962.65..397913.00 rows=3D158204 width=3D8) (actua= l time=3D0.002..0.009 rows=3D85 loops=3D17) Buffers: shared hit=3D59 -> Bitmap Heap Scan on alf=5Fnode=5Faspects aspect=5F1 (cost=3D2962.65..3= 96503.98 rows=3D158204 width=3D8) (ac tual time=3D0.025..0.085 rows=3D85 loops=3D1) Recheck Cond: (qname=5Fid =3D 251) Heap Blocks: exact=3D55 Buffers: shared hit=3D59 -> Bitmap Index Scan on fk=5Falf=5Fnasp=5Fqn (cost=3D0.00..2923.10 rows=3D= 158204 width=3D0) (actual time =3D0.019..0.019 rows=3D87 loops=3D1) Index Cond: (qname=5Fid =3D 251) Buffers: shared hit=3D4 -> Index Only Scan using alf=5Fnode=5Faspects=5Fpkey on alf=5Fnode=5Faspe= cts aspect (cost=3D0.57..34.32 rows=3D12 width=3D8) (actual t ime=3D0.004..0.004 rows=3D1 loops=3D17) Index Cond: ((node=5Fid =3D node.id) AND (qname=5Fid =3D 245)) Heap =46etches: 17 Buffers: shared hit=3D85 Planning time: 0.642 ms Execution time: 0.546 ms (32 rows) With the vacuum and reindex on those tables manage to reduce the time to = 10s from 30s, but still I don't get the exact performance as Instance 2. work=5Fmem was set to 4mb previously and in instance 1 its set to 160mb a= nd instance 2 still using 4mb as work=5Fmem. shared=5Fbuffers set to 8GB in both. Both are on Postgres DB version 9.6.9 Thanks in advance. =46ahiz On 10 Dec 2019, 20:15 +0000, Michael Lewis , wrote:= > On Mon, Dec 9, 2019 at 3:39 PM =46ahiz Mohamed wr= ote: > > > I ran =22explain analyse=22 on this query and I got following resul= t. (We have 2 identical DB instances and they consist of same data. Insta= ne 1 took 20+ second to process and instance 2 took less than a second) > > > > > > Instance 1: (This is used by regular User - More than 600,000 reque= st a day) - The result is same even when there is no user in the server. > > > -> Bitmap Heap Scan on alf=5Fnode node (cost=3D995009.97..33039= 78.85 rows=3D4565737 width=3D8) (actual time=3D3304.419..20465.551 rows=3D= 41109751 loops=3D1) > > > Recheck Cond: ((store=5Fid =3D 6) AND (type=5Fqname=5Fid =3D= 240)) > > > Rows Removed by Index Recheck: 54239131 > > > =46ilter: (NOT (hashed SubPlan 1)) > > > Rows Removed by =46ilter: 2816 > > > Heap Blocks: exact=3D24301 lossy=3D1875383 > > > > > > Planning time: 0.639 ms > > > Execution time: 22946.036 ms > > > > https://paquier.xyz/postgresql-2/postgres-9-4-feature-highlight-lossy= exact-pages-for-bitmap-heap-scan/ > > > > That seems like a lot of lossy blocks. As I understand it, that means= the system didn't have enough work=5Fmem to fit all the references to th= e individual rows which perhaps isn't surprising when it estimates it nee= ds 4.5 million rows and ends up with 41 million. > > > > Do both DB instances have the same data=3F I ask because the two plan= s are rather different which makes me think that statistics about the dat= a are not very similar. Are both configured the same, particularly for sh= ared=5Fbuffers and work=5Fmem, as well as the various planning cost param= eters like random=5Fpage cost=3F If you can provide these plans again wit= h explain( analyze, buffers ) this time=3F Did you check on the last time= autovacuum ran in=C2=A0pg=5Fstat=5Fuser=5Ftables=3F > > > > --5df1495a_a0382c5_142 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
There is a slight different in both instance=E2=80=99= s data. Inastanbce 1 contains latest data and instance 2 consists of data= which is 3 weeks older than instance 1.&=23160;

=46ollowing are the number of rows in each table in= both instances

Instance 1
alf=5Fnode : 96493129 rows
alf=5Fnode=5Fproperties : 455599288 rows
alf=5Fnode=5Faspects : 150153006 rowsInstance 2
alf=5Fnode : 90831396 rows
alf=5Fnode=5Fproperties : 440792247 rows
alf=5Fnode=5Faspects : 146648241 rows

I hope the above data difference can make a drastic= difference. Please correct me if I am wrong.

I checked =22pg=5Fstat=5Fuser=5Ftables=22 and autov= acuum never run against those tables.

I did execute vacuum manually and I noticed the bel= ow in the output

=22IN=46O: vacuuming =22public.alf=5Fnode=5Faspects= =22
IN=46O: =22alf=5Fnode=5Faspects=22: found 0 removab= le, 150264654 nonremovable row versions in 812242 pages
DETAIL: 0 dead row versions cannot be removed yet.<= /div>
CPU 13.53s/33.35u sec elapsed 77.88 sec.


IN=46O: analyzing =22public.alf=5Fnode=5Faspects=22=
IN=46O: =22alf=5Fnode=5Faspects=22: scanned 30000 o= f 812242 pages, containing 5550000 live rows and 0 dead rows; 30000 rows = in sample, 150264770 estimated total rows=22

Did the vacuum worked fine=3F

I did =22explain( analyze, buffers )=22 below are t= he results:

Instance 1:&=23160;

&=23160;Nested Loop Semi Join (cost=3D441133.07..13= 52496.76 rows=3D1 width=3D8) (actual time=3D9054.324..10029.748 rows=3D22= loops=3D1)
Buffers: shared hit=3D1617812
-> Merge Semi Join (cost=3D441132.50..1352359.19 rows=3D41 width=3D16)= (actual time=3D9054.296..10029.547 rows=3D22 loops=3D1)
Merge Cond: (node.id =3D prop.node=5Fi= d)
Buffers: shared hit=3D1617701
-> Index Only Scan using idx=5Falf=5Fnode=5Ftqn on alf=5Fnode node (co= st=3D441041.93..1340831.48 rows=3D4593371 width=3D8) (actual t
ime=3D4.418..7594.637 rows=3D40998148 loops=3D1)
Index Cond: ((type=5Fqname=5Fid =3D 240) AND (store=5Fid =3D 6))
=46ilter: (NOT (hashed SubPlan 1))
Rows Removed by =46ilter: 130
Heap =46etches: 0
Buffers: shared hit=3D1617681
SubPlan 1
-> Bitmap Heap Scan on alf=5Fnode=5Faspects aspect=5F1 (cost=3D3418.63= ..440585.22 rows=3D182459 width=3D8) (actual time=3D0.
583..2.992 rows=3D4697 loops=3D1)
Recheck Cond: (qname=5Fid =3D 251)
Heap Blocks: exact=3D1774
Buffers: shared hit=3D1791
-> Bitmap Index Scan on fk=5Falf=5Fnasp=5Fqn (cost=3D0.00..3373.01 row= s=3D182459 width=3D0) (actual time=3D0.384..0.38
4 rows=3D4697 loops=3D1)
Index Cond: (qname=5Fid =3D 251)
Buffers: shared hit=3D17
-> Index Only Scan using idx=5Falf=5Fnprop=5Fs on alf=5Fnode=5Fpropert= ies prop (cost=3D0.70..41.74 rows=3D852 width=3D8) (actual time=3D
0.022..0.037 rows=3D23 loops=3D1)
Index Cond: ((qname=5Fid =3D '242'::bigint) AND (string=5Fvalue =3D 'E292= 432'::text))
Heap =46etches: 0
Buffers: shared hit=3D20
-> Index Only Scan using alf=5Fnode=5Faspects=5Fpkey on alf=5Fnode=5Fa= spects aspect (cost=3D0.57..38.80 rows=3D14 width=3D8) (actual time=3D0.<= br /> 007..0.007 rows=3D1 loops=3D22)
Index Cond: ((node=5Fid =3D node.id) A= ND (qname=5Fid =3D 245))
Heap =46etches: 22
Buffers: shared hit=3D111
Planning time: 0.621 ms
Execution time: 10029.799 ms
(29 rows)


Instance 2:&=23160;

Nested Loop Semi Join (cost=3D6471.94..173560891.23= rows=3D2 width=3D8) (actual time=3D0.162..0.470 rows=3D17 loops=3D1)
Buffers: shared hit=3D257
-> Nested Loop (cost=3D6471.37..173560734.51 rows=3D45 width=3D16) (ac= tual time=3D0.154..0.392 rows=3D17 loops=3D1)
Buffers: shared hit=3D172
-> HashAggregate (cost=3D3508.15..3516.80 rows=3D865 width=3D8) (actua= l time=3D0.039..0.043 rows=3D18 loops=3D1)
Group Key: prop.node=5Fid
Buffers: shared hit=3D23
-> Index Only Scan using idx=5Falf=5Fnprop=5Fs on alf=5Fnode=5Fpropert= ies prop (cost=3D0.70..3505.99 rows=3D866 width=3D8)
(actual time=3D0.019..0.033 rows=3D18 loops=3D1)
Index Cond: ((qname=5Fid =3D '242'::bigint) AND (string=5Fvalue =3D 'E292= 432'::text))
Heap =46etches: 18
Buffers: shared hit=3D23
-> Index Scan using alf=5Fnode=5Fpkey on alf=5Fnode node (cost=3D2963.= 22..200644.17 rows=3D1 width=3D8) (actual time=3D0.019..
0.019 rows=3D1 loops=3D18)
Index Cond: (id =3D prop.node=5Fid)
=46ilter: ((type=5Fqname=5Fid <> 145) AND (store=5Fid =3D 6) AND (t= ype=5Fqname=5Fid =3D 240) AND (NOT (SubPlan 1)))
Rows Removed by =46ilter: 0
Buffers: shared hit=3D149
SubPlan 1
-> Materialize (cost=3D2962.65..397913.00 rows=3D158204 width=3D8) (ac= tual time=3D0.002..0.009 rows=3D85 loops=3D17)
Buffers: shared hit=3D59
-> Bitmap Heap Scan on alf=5Fnode=5Faspects aspect=5F1 (cost=3D2962.65= ..396503.98 rows=3D158204 width=3D8) (ac
tual time=3D0.025..0.085 rows=3D85 loops=3D1)
Recheck Cond: (qname=5Fid =3D 251)
Heap Blocks: exact=3D55
Buffers: shared hit=3D59
-> Bitmap Index Scan on fk=5Falf=5Fnasp=5Fqn (cost=3D0.00..2923.10 row= s=3D158204 width=3D0) (actual time
=3D0.019..0.019 rows=3D87 loops=3D1)
Index Cond: (qname=5Fid =3D 251)
Buffers: shared hit=3D4
-> Index Only Scan using alf=5Fnode=5Faspects=5Fpkey on alf=5Fnode=5Fa= spects aspect (cost=3D0.57..34.32 rows=3D12 width=3D8) (actual t
ime=3D0.004..0.004 rows=3D1 loops=3D17)
Index Cond: ((node=5Fid =3D node.id) A= ND (qname=5Fid =3D 245))
Heap =46etches: 17
Buffers: shared hit=3D85
Planning time: 0.642 ms
Execution time: 0.546 ms
(32 rows)

With the vacuum and reindex on those tables manage = to reduce the time to 10s from 30s, but still I don't get the exact perfo= rmance as Instance 2.

work=5Fmem was set to 4mb previously and in instanc= e 1 its set to 160mb and instance 2 still using 4mb as work=5Fmem.&=23160= ;

shared=5Fbuffers set to 8GB in both.

Both are on Postgres DB version 9.6.9

Thanks in advance.

=46ahiz
On 10 Dec 2019, 20:15 +0000, Michae= l Lewis <mlewis=40entrata.com>, wrote:
On Mon, Dec 9, 2019 at 3:39 PM =46ahiz Mohamed <<= a href=3D=22mailto:fahiz=40netwidz.com=22>fahiz=40netwidz.com> wro= te:
I ran =22explain analyse=22 on this query and I got= following result. (We have 2 identical DB instances and they consist of = same data. Instane 1 took 20+ second to process and instance 2 took less = than a second)

Instance 1: (This is used by regular User - More th= an 600,000 request a day) - The result is same even when there is no user= in the server.

     -> Bitmap Heap Scan on alf=5Fnode node (cost=3D995009.97=
..3303978.85 rows=3D4565737 width=3D8) (actual time=3D3304.419..20465.551=
 rows=3D41109751 loops=3D1)
= Recheck Cond: ((store=5Fid =3D 6) AND (type=5Fqname=5Fid =3D 240))
Rows Removed by Index Recheck: 5= 4239131
=46ilter: (NOT (has= hed SubPlan 1))
Rows Remove= d by =46ilter: 2816
Heap Bl= ocks: exact=3D24301 lossy=3D1875383

Planning time: 0.639 ms
Execution time: 22946.036 ms


That seems like a lot of lossy blocks. As I understand it, that mean= s the system didn't have enough work=5Fmem to fit all the references to t= he individual rows which perhaps isn't surprising when it estimates it ne= eds 4.5 million rows and ends up with 41 million.

Do both DB instances have the same data=3F I ask because the two pla= ns are rather different which makes me think that statistics about the da= ta are not very similar. Are both configured the same, particularly for s= hared=5Fbuffers and work=5Fmem, as well as the various planning cost para= meters like random=5Fpage cost=3F If you can provide these plans again wi= th explain( analyze, buffers ) this time=3F Did you check on the last tim= e autovacuum ran in&=23160;pg=5Fstat=5Fuser=5Ftables=3F


--5df1495a_a0382c5_142--