pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ldh@laurent-hasson.com <ldh@laurent-hasson.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Big performance slowdown from 11.2 to 13.3
Date: Tue, 27 Jul 2021 23:15:52 -0400
Message-ID: <543673.1627442152@sss.pgh.pa.us> (raw)
In-Reply-To: <MN2PR15MB2560987D103C712238C706AB85EA9@MN2PR15MB2560.namprd15.prod.outlook.com>
References: <MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com>
	<20210721191528.GC19620@telsasoft.com>
	<MN2PR15MB256016E33F00DE60B96F02D385E39@MN2PR15MB2560.namprd15.prod.outlook.com>
	<CAH2-Wzm3rSAWHyENb3T0X8M_qdYjF1t7rntkMJ2kDiuhVOHx3g@mail.gmail.com>
	<MN2PR15MB2560C1A890DC07F9359FB56285E39@MN2PR15MB2560.namprd15.prod.outlook.com>
	<732758.1626911007@sss.pgh.pa.us>
	<MN2PR15MB2560778595BB7AF6E691B26785E39@MN2PR15MB2560.namprd15.prod.outlook.com>
	<MN2PR15MB2560D429866BD65A70574A6C85E49@MN2PR15MB2560.namprd15.prod.outlook.com>
	<CAApHDvqoF7y7SQjGT=940njnAd_CUcUG6oRYChcP_+eJyuNiug@mail.gmail.com>
	<MN2PR15MB25603D3CE06C8F9C312EA58985E49@MN2PR15MB2560.namprd15.prod.outlook.com>
	<MN2PR15MB2560E4574A6E2B5AED2C03CB85E49@MN2PR15MB2560.namprd15.prod.outlook.com>
	<784576.1626968702@sss.pgh.pa.us>
	<785218.1626969409@sss.pgh.pa.us>
	<CAApHDvo+Gb80BVPKYCwHbLa7a7ZXp9ziq9URrpQaKdvXsd46bg@mail.gmail.com>
	<786600.1626970898@sss.pgh.pa.us>
	<CAH2-WzmftijCna_aY-HyCUfsww! ! ! fPCC4d2HjKab1cxM0QCFrRUQ@mail.gmail.com>
	<787780.1626972122@sss.pgh.pa.us>
	<MN2PR15MB25609F3505A6FB441CAB22A585E49@MN2PR15MB2560.namprd15.prod.outlook.com>
	<171155.1627236507@sss.pgh.pa.us>
	<MN2PR15MB2560987D103C712238C706AB85EA9@MN2PR15MB2560.namprd15.prod.outlook.com>

"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> One question that popped up in my head. hash_mem_multiplier is an upper-bound right: it doesn't reserve memory ahead of time correct? So there is no reason for me to spend undue amounts of time fine-tuning this parameter? If I have work_mem to 521MB, then I can set hash_mem_multiplier to 8 and should be OK. This doesn't mean that every query will consume 4GB of memory.

Yeah, I wouldn't sweat over the specific value.  The pre-v13 behavior
was effectively equivalent to hash_mem_multiplier = infinity, so if
you weren't having any OOM problems before, just crank it up.

			regards, tom lane





view thread (59+ messages)  latest in thread

Message-ID: <543673.1627442152@sss.pgh.pa.us>
Permalink:  ../543673.1627442152@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/543673.1627442152@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, ldh@laurent-hasson.com, pg@bowt.ie, dgrowleyml@gmail.com, pryzby@telsasoft.com
  Subject: Re: Big performance slowdown from 11.2 to 13.3
  In-Reply-To: <543673.1627442152@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox